Is what I have thought after taking another look at this site after about 7 or 8 months of not visiting. One of the reasons I'm bringing up this site (is has been around for quite a while) is that it is snowing in Zanpo! This is really cool, not only that, they must have had to recreate every block they had to show snow. Amazing work.
There was a question on their forum as to how to make it more popular as things have slowed down a bit. My first thought would be to incorporate FCS into this. How many users are on at the moment, their info, where they are, teleport to them, chat, see their vid, pick a fight whatever. If you could provide you're own avatar (the walking dude) that would be cool too. Have some town hall meetings there where everybody would gather in one room and the person in charge would have the floor, do a presentation, show some vid.. all kinds of stuff comes to mind. There are so many MORE options when you have when you have live data flying around.
This site really blows me away, but there is so much more that can be done.
For any of you on the figgyleaf flashcom mailing list this isn't much new news to you but I've been working my a$$ off trying to get tunneling to work properly on a windows server. I work in an environment where the network is tighter than a .... well.. you fill in the blank there ;) , and nothing gets in or out that the network meanies don't look at first. Heck... we aren't even allowed to use outside mailing systems like msn or yahoo.
Anyways, the servers that I can connect up to are... Linux. Yes it's true. If you have a Linux flashcom server I am 99% sure I can connect up to it on the first try. But a windows server I can't. SO.. I have been doing some research on the subject because I would really like to get the darn thing working (though I've been having a tough time getting MM to help out a bit on the subject :( ) They are busy folks maybe. But! Thanks to The God of Flashcom Srinivas Manapragada I now have a super script in my hands (compliments to Peldi for putting it up).
With this magical script, I can connect to my windows server 1 out 5 tries or so. The funny thing is that it'll connect on a different port everytime. Timing out and failing are all sporadic and there is no real pattern. I have noticed though that normal RTMP on default (no port number after the server name) connected up the most. About 3 times out 12 or 13 tries. The next best was 1935 and then 443 on RTMPT. The default of RTMPT never hooked up and neither did setting the port on normal RTMP. Lastly, setting the RTMPT port to 80 hooked up about once I think.
Out of this experience I have found it is best NOT to set the port for RTMP as it seems to be special or something and checks out all kinds of ports for you, whereas it's a good idea to set the port for RTMPT. But in these cases... why would one fail and the other not? Why is it not the least bit constant? Still a mystery but I'm still on it. Just need a linux server to test with and MT won't get back to me on my inquiry on a new account....(I'm pretty sure they run off of Linux) Talk about poor customer service, it's been over a day since I sent out my last email and no reply whatsoever. :(
My advice so far though (even though MM says there is no dif) is to DEFINITELY go Linux. Don't do the windows thing... there's something fishy going on with that server... not only that the setInterval() doesn't work properly... ;)
This problem can be reproduced by putting two avpresences on the stage with a simple connect, connecting up with two different computers, publishing with both then stop publishing and swap avpresences. The loopback from the camera will stop working but it will still publish properly. In other words you won't be able to see yourself anymore. I cannot get this to happen with the flash 6 player/plugin though. Only flash player/plugin 7. It's not just the avpresences that do this, all video objects do it. So if you have your own version of the avpresence it'll stop working properly (but only on the flash player/plugin 7).
read on for the fix/workaround
What I think is happening here is the video object is not able to reinitialize itself to accept the camera object again. Reinitializing the camera didn't work so what I did to get my apps to work in 6 or 7, was to place a video object in a movieclip. Use linkage and attachMovie to get it on the stage when somebody is going to play or publish and attach the video to that.
It works, and you won't hear your clients saying to you that your apps are weird and buggy. Nobody wants to hear that. But it's a crappy thing that we have to get around another bug in flash. I have posted it to MM's site though, so hopefully we'll see some action soon.
I'm sure there are others that feel the same way I do. There are some bugs in FCS that are truly annoying. Why does the title say they are not a bug? well it's not that they aren't a bug, but when it's brought up to MM they will never say it's a bug. Most likely "it's being looked into". Not to flame MM though. They did get a nice patch that made FCS 1.5 a lot more stable.. I won't even start on FCS 1.0, we can call that a public beta or something....
I'd like to make this post less of a rant and much more of a useful post by mentioning a couple of the workarounds for the "non-bugs".
1. setInterval() on the server side on Windows. Linux seems to be fine, in fact the patch fixed it for linux but messed it up for Windows. The other funny thing is that this only happens on virtual hosts. How do you get around this? Clear your interval everytime you run the function that it's supposed to run. Then set it again. But this bug doesn't exist :) But it's being looked into.
2. If there is no action in your app between you and the server for a few minutes, you will stay connected but FCS will not respond to your pleas to do something. This is weird too. You are connected, which means you are alive and well to FCS, but the calls, or onSyncs stop working. How do you solve it? Set up a pinger function. You'll need to send some data, or get some data, or call a function on the server to make sure that the server understands you are still there. I recommend doing this every minute. If you have bought Phillip Kermans new book, you probably have read that he has the same recommendation, and if I remember correctly he brought it up (to no response) in the Chattyfig flashcom list. This isn't a bug, nor is it being looked into.
3. onDisconnect() doesn't get called on the server when a client disconnects. Yes.. this is a biggy. You need to let a few people know that this client has disappeared out of the app. This generally happens when the user doesn't use a close() method on the netConnection and just closes the browser or desktop app. How to get around this one? Ping the client every 5 seconds or so.... if the ping doesn't come back.. they are not there? Theoretically yes. Not sure if this is a bug of FCS or the flash player. Sure wish there was some more input from MM on this. A lot of people have brought this up.
4. When playing a video and you pause it, all the video/audio that was in the buffer... disappears. This sucks and there is no way around it, especially if you have buffered a nice amount or you are on a dial up, or BOTH! Ah well..
5. On high quality video publishing 95 or so, and putting the size at the highest the camera can handle, the first time you speak into the mic (or make any sound) the video will stop being sent to FCS for a few seconds. Though if you make a noise in the mic before publishing (to initialize the audio in the flash player?) it will usually work fine. This happens only on the first time of making some kind of noise into the mic. This is totally weird, and I have only had it happen in one app. Though my publishing code is absolutely no different between apps so I know it's not that. The only thing I could think of was the quality and size of the video. Bug? not sure. But no response from MM which means they are either baffled and don't want to touch it with a ten foot pole or they have seen it too and hope the cat doesn't get out of the bag. But I don't see MM as that kind of company. Most likely a flash player problem more than an FCS problem
I think that's about it for now. I'm sure there are others but I can't recall them to mind, which means they aren't so big. If anybody else has a funny bug (but not a bug) speak up a bit. I'd like to know, and I'm pretty sure MM reads everything they can. If I'm wrong on any of the above and there is a real reason as to why they happen I'd like to hear that too. Until then... it's workaround time, but this of course is for any software out there.
To conclude, I would like to say that for the most part FCS is absolutely rad and I can't wait to see what they bring out in the next version. I work with it every single day and I have quite a few desktop apps that I use everyday, if I didn't have them I'd be screwed. Lots of work thinking of all the variables you get with live data, vid, aud, connections, SO's, but... it's a lot of fun. :)
One of my recent projects included the development of a small font browser/viewer application, which is launched from an active desktop containing various little tools to help in media design (font browser, color scheme planner, links to programming/scripting resources and various syntax lookup.).
The font viewer generates a list of the available fonts on a users system using the getFontList() method of the TextField class. Functionality includes the option to select a font name and have it applied to default text, input custom text, apply formatting (bold, italic) and set point size. I knew when going into this that not all fonts on a system would be readable. For example, Adobe PostScript/Type1 fonts, however a problem I ran into was a large number of Japanese fonts on my system would not correctly display, although they did appear in the generated font list. My first thought was that I had made a scripting error or not included the proper formatting. After looking through the code and browsing some online resource I was at a loss. While one font would display perfectly, the next in the list (from the same font house and font family), would not. Rather clueless at this point, I turned to Graeme to pick his wealth o' Flash knowledge, but still could not figure out the problem (Thanks for the help anyway Graeme!)
*Note: Setting the System.useCodepage property to true made no difference.
After all this, I assumed the problem must have its origin outside the Flash Player. Read on to see what I found.
As I mentioned previously, I was aware some fonts would or would not display in the font list, however I DIDN'T know that some fonts would be listed, but not be fully supported. I figured this out after I opened up my fonts folder (working in Win2k) and looked for the specific fonts not displaying...and was hit with the fact that they were a different flavor or TrueType. Rather than your standard True Type Font (TTF), these were True Type Collection (TTC) fonts. It turns out that none of these (Japanese or otherwise) would display correctly when applied in the font browser.
After figuring that out, I went ahead to experiment with another format as well, OpenType. With OpenType, it is really impossible to tell if they will display or not. Simply put, some will and some won't. Because OT can have different extensions and allow for greater options for the type designer (encoding, type of curves, etc), you just have to test to see what will work and what will not.
Below are examples of the icons (win2k) for each font format I mentioned above. Maybe this information was already common knowledge, but if not, I hope someone finds it useful and they do not have to waste as much time as I did finding the cause of the problem.

Finally, it should be noted that while they did not display in the font browser, all three (True Type, True Type Collection and OpenType) displayed perfectly within the Flash authoring environment.
Yes.. still teaching FCS here. Since it is such a new concept in Japan that you can actually build applications in Flash, the first thing that I have to get across to my young geniuses here (and management) is that Flash isn't for stupid animations anymore. Not in my department at least. With the app that I got out for the training (see a post below on debugging) it really opened everybodys eyes here that Flash is more than for crappy animations that just annoy you.
So I've started out by explaining how close actionscript is to Javascript and server side script for FCS is even closer. Which helped a lot because now they (hard studying youngsters) now have a springboard to jump off of.
Read on for more on this...
When teaching something from step 1, if somebody doesn't understand the concept of what you are teaching it'll be a lot harder to explain what's going on. For example learning a new country's language. If the teacher can find someway to show that this new language is somehow related to what the student is already familiar with (like English and Spanish maybe, but not Japanese and English... In a case like this, you would try to explain the blatant differences, best if you can find opposites) then the learning process should go along a little less painlessly.
Going on that idea, I explain some of the closer concepts to Javascript, and the concept of OOP which can actually apply to almost any technical language. All of a sudden a light comes on in my happy students little eye and she has now mastered (within two weeks) the basics of flash actionscript and has built a chat app, video recording, video playing (with scrubber), shared object saving, and mastered the basic concepts of the netConnection, netStreams and how objects, arrays, and functions work. Of course the concepts there aren't so different than other languages but I have never seen anybody pick up so quick on something. Mainly because Flash is not just a language, you need to design with it too. Name instances, figure out layers, and levels.
Hopefully soon I can get her (yes she's a she - this in line with a few comments on other blogs that there aren't many women in this type of work) to move into XML and also Remoting because we have it all here and I really want to get more apps out that pull in data from DB's.
Hopefully this thread will continue in a happy direction sometime soon. Will post then :)
For those of you out of the mobile loop, there is currently a series of mobile phones here in Japan (505i/is series from NTT DoCoMo) that can play Flash Lite content. Besides the restrictions of Flash Lite (Flash 5.0 objects and Flash 4 AS), the file size cap for SWF files is 20kb. This includes the size of the html document if it is embedded. There are more restrictions, but I won't go into those here. With that out of the way, I will get to the news.
It has been announced that the next generation of the FOMA handsets from DoCoMo will support up to 100kb SWF movies! Maybe I am the only one excited...
FOMA (Freedom of Mobile multimedia Access) is the W-CDMA based 3G generation mobile service that was launched in Japan in October of 2001. Unlike many other 3G initiatives around the world that never took off (or are still trying), FOMA has enjoyed relative success and is commonly available and used throughout Japan. Data transfer rates are up to 64kbps upstream and 384kbps downstream.
For more info (in English), check out nttdocomo.com
I'm teaching FCS here at work now. We have too many apps that need live data, or video/audio work that I can't build them all myself.. and don't want to either. So it's on to the younger generation of quick and bright minds. I shall now pass down all my accumulated FCS knowledge so I can finally take a break from coding and coding and coding..
Though I do have to say, coding for FCS is a lot more interesting than just Flash apps. Just flash stuff might have a form or two, some buttons, maybe a bit of xml getting read in and creating a menu or something, but it just doesn't compare to seeing live data or whatever flashing across screen when you hook up. Everybody in their dog has created a chat app at least once, but very few have created a high quality chat app out there. When I mean high quality, I'm talking above MSN or Yahoo messenger. I'm talking redundancy, information messages if you're cut off, line is slow, extra options like emoticons or sounds that you can customize. But believe it or not, MSN and all other chat apps have that. What makes FCS a better chat is all that and you can design it, shape it, put your own logo on it, control it.. pretty much whatever you want. But that's another story that I'm sure I'll get back to soon enough here. I'm interested in getting out a few words on teaching.
When teaching people what you know, it's hard not to get frustrated when they "don't get it". You explain a concept of how something works, and they say yes they understand and you move on. Come back to it later and they are like "we went over that?"... and you're like.. "yes..." and time stops for a few seconds as you both think the same thing. "WTF".
SO, take a step back as to what you know and try to remember when you didn't know. Bring back from the far recesses of your mind that horrible feeling of being confused and lost when netConnection.connect() was mind boggling and you were wondering why you had to connect to the connection, stream, and SO. How come one doesn't do it all?? Does it mean I'm making more than one connection? At least that's what I thought a while back.
It's not so daunting a task I think. Take things slow, make sure you have a goal in what you want to teach. I have taken an approach of assigning tasks that I would like to see done. For example, a chat app that will show a list of the users, chat area, login area, and the fact that you can press enter or the send button to send a chat. NO COMPONENTS... damn them... Simple app eh? Or so you'd think. There are quite a few ways to get the above done, but which is easiest? best? most effecient and bug proof? Those are the keys I think. Then it just goes from there, we move on to video/audio. Play the vid, pause it, give it a playing bar that you can scrub on... things like that.
I'll try to touch more on my experiences of teaching technical stuff like this. I do have experience in teaching other topics, but this is my first for FCS. Should be interesting.
I was recently reading an article in the new edition of ID (The International Design Magazine, Nov 2003), which was a Q+A with information design evangelist Edward Tufte. It only reinforced what I and many others have known all along.... PowerPoint is crap.
It puts the power in the hands of a lot of individuals to make presentations, who probably should not be making presentations (or at least visual presentation materials). Now, I am NOT talking as a snobbish designer here. While ugly design in one thing (don't get me started), the failure of a medium on a whole to actually be able to properly convey information and educate the audience is another. It seems that most presenters fall back on PowerPoint simply to give the audience something to stare at, in case what they have to say is not enough to keep attention. Is there hope?
Quote from article:
-------------------------------------------------------
"The minimum we should hope for with any display technology is that it should do no harm."
-------------------------------------------------------
You can read excerpts of the article at http://www.idonline.com/qa/
Mr. Tufte has also written an Essay on the topic, The cognitive Style of PowerPoint, that can be obtained from his site (http://www.edwardtufte.com/tufte/powerpoint) for $7 (USD). Also a nifty poster that made me chuckle.
*This is in no way meant to be an advertisement

Well, I have finished up the project I mentioned in my previous post. The programs used included Swift 3D, Flash and Photoshop. If you want to view an excerpt which contains just the effect I was talking about, you can download an avi from here. While it is half the actual size and compressed, it still weighs in at around 4mb. The original was 500mb.
For more information and some suggestions, read on.
The animation and modeling were not really difficult, although a little time consuming. The BIG time eater was rendering in Swift. For those of you that do not know, the Swift 3D EMO (raster) rendering engine, relies on a software based rendering and not hardware.
A few suggestions should you decide you want to try something like this.
1. I do not suggest trying something on this scale with Swift if your workstation is running less than a 2ghz processor and 1gig of ram. While you could still do it on less, the delay in moving objects on the stage and horrendous rendering times would make it frustrating. On a system with a 1.8ghz P4 and 524mb of ram, rendering crawled. When I say crawled, I am talking in the area of grinding through only 30 frames in 7 hours. (Time can increase/decrease depending on if there is a lot of transparency and/or reflections used). On a 3.04 ghz Xeon and 1.5ghz of ram, I managed 200 frames in about the same time.
2. Planning is crucial. The amount of objects being moved around the stage, coupled with Swifts rather unforgiving Undo system, can make fixing small animation errors a disaster. Storyboard your animation and while working, do a lot of test renders, which leads into my next point.
3.With the rendering times mentioned above, you DO NOT want to have to re-re-render due to problems that could have easily been caught in a test that takes a wee fraction of the time. When testing, do not rely on the scanline renderer within the Scene Editor for all comping. Switch over to the Rendering and Export editor to make sure you are getting a clear view of what things will REALLY look like.
4. If you are working against the clock, make sure you have figured in rendering time (and re-rendering time in case of error) into the project schedule. Setting up your production schedule so that you can render overnight helps.
5. Finally, if you do not have the option to render overnight, having an extra puter to play Halo (Multiplayer online) helps to waste ti....errr, helps you wait patiently, while anticipating seeing the final rendering of your masterpiece. (An ample supply of your favorite alcoholic (if you partake) beverage doesn't hurt either.)
BUG ALERT
While working though this project, I came across an apparent rendering bug in Swift that had crossed my path once before. This was extremely frustrating, as it DID happen while rendering overnight and test renders had not shown it.
If you have a light source that is set so that it does not create shadows and are working with transparent materials, occasionally those objects with transparency will show up as black (or a lot darker) when exported in a raster format that does not support alpha transparency (JPG in my case). This DOES NOT show up during rendering, only after exporting and is not consistant. The first five frames could look fine and POW, the sixth has your beautiful transparent model looking like a lump of obsidian.
That said, make sure to check your exported files BEFORE closing the Render and Export editor, as Swift will allow you to change the raster export format without having to re-render.
If you have any question regarding this effect please feel free to email me or post a comment.
OK.. I've finally finished up the greuling one week of support for my FCS application that I mentioned just a little in my last post here. It wasn't so bad really other than the fact that I had to work when everybody else wasn't. To put the app in a nutshell, it's a very high-traffic video phone system for a currency dealing game/training.
Dealers are very very short tempered people who's only goal in life is to make money. Anything that slows them down in making that cash is as good as dead. I've heard many a scary story from support teams for these guys, along with a funny one that a guy was so pissed he busted his keyboard over his knee and threw it across the room. He then told the support guy that his keyboard isn't working and to hurry up and get him a new one... ah well, getting off topic here.
So, anyways the app went really well but I found debugging a bit tough due to the high speed in which these people would be calling other banks (there are up to 16 banks in a session). The calls are usually finished within a minute, after selling or buying some currency, and then they are off to the next call. I tried running through the traces on the server side of FCS, but that wasn't going well as it was scrolling so fast at times that it just wasn't readable. Not only that, scrolling in flash sucks up so much CPU that it has an effect on the FCS app... that sucks.
It just so happens though that I had set up some remoting to keep track of who called who and if it got through or not (this app actually has a waiting option if one bank really needs to get a hold of another bank). So we could track later who was a busy bank calling everyone in their dog, and who wasn't. This was quite handy, but I had forgotten to put a time stamp in there so it was extremely tough to track down my only bug in the system.. cross calls. When a cross call happened in the beginning the main problem was that the conversations were so alike that the person who wasn't supposed to be in the call would be able to follow along with a conversation that wasn't being had with them. They could hear the other call and that wasn't good as it would be taken that they were buying/selling currency to/from that bank. So I had to debug this puppy right then and there or there would be a lot of banks short or long on money...
Read on for look at my debugging approach..
The main reason this bug made it into the production version of this app is that we didn't have enough people or time to properly test when so many people are calling others at the exact same time. Whether they would be sitting in somebody elses waiting list or just happened to catch them inbetween calls or whatever. The options seemed endless. But there was a method to my madness and I was definitely going to track it down.
Problem: Two people would be able to call the same person
Sub problem: and the person who didn't make it through to that person could hear the current conversation.
Frequency: Rare... hard to duplicate
At the very least I had to get rid of the sub-problem. The weirdest thing is that it was theoretically impossible to call the same person as I had set them as busy as soon as one person made it through.
So on to the debugging. I first wondered if there was something not making it to the server. It is at the server where I am setting whether they are busy or not and if a call can be made or if that person should go into that persons waiting list. At this time, all changes were sent from the client, unfortunately if two people accessed (read) a value before it was set then there was the possiblity that two people could call one person. The biggest thing I needed to know is the timing of when this happened, so I immediately changed up the code that makes the inserts into the DB for logging to show the time when each call was made. This helped. I found two different patterns. Due to being able to see the time at which a call was made, whether that person was on a call (or should have been on a call). As all FCS developers know, FCS's logging tools... well.. suck. You have to use flash to read them and not only that, they aren't a very readable format. By putting everything into a DB and then looking it later using queries, it's quite easy to pinpoint where something is going wrong. I strongly recommend getting into remoting from the FCS side. Very handy.
So the two patterns were 1. Two banks would call one bank at the exact same time. 2. Even though a bank was busy, somebody would be able to call them and that would cut off the first person. These patterns were figured out by checking the call number and time it was made all from the DB.
Running through my code, I realized one thing about FCS apps.. If there is anything that you want only one person to do or access, do it all server side. I had a check on the client side to see if the person they were calling was busy or not then make the call from the client side. If I were to rebuild this app from the beginning, I would definitely use all server side script that would tell the clients what to do and when. The second pattern was a bit weirder because I think it had to do with the busy list. When somebody became free they would check their busy list (stored in an SO array) and if somebody was in there they would call them. Supposedly the person who is waiting is not talking to somebody else, but I think with the frequency of calls that were made (1000's within 30 minutes) somewhere along the line, a list didn't get cleaned out properly. *sigh* There was no easy to way to fix this one yet so I concentrated on making sure that the person who didn't get through or was cut off weren't able to keep listening to the conversation. This was done with a little trickery of making sure that their feed was being sent using their bank number and call number combined. You might be thinking, well.. wouldn't the person who received two calls at the same time be connected to both calls? nope, I thought of that and made sure that before I published a feed to make sure to unpublish first. That stopped the feed that was going to the first person (or whoever was getting cut off).
In the end, I didn't solve the main problem, but did manage to reduce confusion as now the person who got cut off was staring at a frozen image, or nothing. They could hang up and call the next person.. a little peeved maybe, buy it was only training and not the real thing.
The idea behind this debugging story is that you can't be too careful in your coding. When it comes to FCS stuff, everything is live, you have to think of so many more things. When to cut off feeds, start them, send messages to whom and when from where and if that is supposed to get a response then do something with it. Do people double click? Do they move the mouse off the button after they click? All kinds of stuff. Once again, I'll go into the little bugs in another post... I've typed for too long :)
With RIA des/dev being a deservedly hot topic, I have read developers claiming that their apps will "Change the way you work.". My thought on this is along the lines that changing the way our clients work should not be the goal when designing/developing an application. The point should be to create an application that is flexible enough to adapt to the way the client works, not the other way around.
Most people have developed their own style of working that, well, works for them. While we should surely strive to create tools that help them make the tasks at hand easier and/or more efficient, if the solution created attempts to make them totally change the way they are accustomed to working, more than likely, it will simply be an application that gets shelved. This in and of itself is an extreme failure in usability.
To put in in perspective, how would most designers/developers feel if their next client said, "For this one, I want you to forget about the normal workflow you have developed for projects and instead do it the way I tell you."
And it is an art, make no mistake. I've just spent the last 3 hours trying to find out where the timing is off on a live app that is actually in major use even as I type this blog. (more on this later) But debugging isn't just looking at code and seeing if you are setting your vars properly. It's a matter of being able to see into the future. How are the users going to use the app, are they going to double click, single click, are they going to release the mouse outside of the button, will they accidently close the app halfway through.. there are thousands of possiblities out there and to be a good app, a perfect app, you have to think of them all and find a way to handle those errors.
Also, working with FCS, all the data is live. In an environment where even the slightest millisecond counts, your sight into the future had better be as clear as a bell or your app will fail.. More on this later as I gotta get back :)
I am currently working on a broadcast motion graphics piece using Swift as the primary 3D modeling and animation tool, with post-production in Flash and finally converted into a broadcast video format. I wanted a particle like effect, however since Swift lacks a scripting language, it had to be done the old fashion way...by hand. The below shots give an example of the effect. The actual piece is 720x540 and will be approx. 400 frames at 30fps, so is too large to put online, however I will see about getting a web friendly version once the deadline has been met.
While it looks pretty busy, the scene is actually only composed of around 88,443 edges (55,193 polygons).

I know of a few places on the net that have forums that are dedicated to FCS. Others have FCS sitting inside a "Server related" forum. I'm curious though as to which is best.
I try to get involved on MM's forum, and Flashkit because everybody knows those too. I was also a little involved on the Ultrashock forum, but nobody really posts there on FCS. Another thing that sucks about Ultrashock is that it's hard to bookmark stuff or print it because it's all frames..but that's a different subject. Flashkit gets a bit of traffic though so I try to answer the most realistic questions when I get some time. On MM's forum I managed to keep up with things for a while when I really wanted to study FCS. I have found that one of the best ways to learn is not so much as being a virtual wall flower and reading everything, as to actually getting in there and trying to solve problems that others are having. In that way, I really got involved with flashcomstudio and did a few tutes along with moderating half the forum, which is completely dedicated to FCS. Unfortunately for them, they aren't managed too well anymore and I have a pretty good feeling it won't be up for much longer.
There's also "we're here", which I'm never there, though I do have an ID, so I don't really know what's going there, but I do know that quite a few of the more knowledgable are there who I never see on Flashkit and very rarely on MM's forum. Does this make we're here the most reliable then? Is it most popular? Looking at the post count for there it's not...
I would love to see a site (a well done site) that is dedicated completely to Flash Communication Server. Code, forum, tutorials and news. And in more than one language.
In the Lord of the rings site, there is what I would call an RIA. You can see how things were built by video with audio, and just in case you don't have audio, there are comments that run with the video on the side. Also 3 different sections that are viewable. Easy to use, easy to understand, very well built I think.
On a side note that doesn't have so much to do with flash, I really liked how they explained about lighting and effects they did. Very very interesting stuff I think, definitely something I'd like to get into. The lighting alone can change the feeling of a scene completely. Not only that they have normal people, graphics, 3d models and effects that all have to match up. I've tried this a bit with some keyed material that I shot and it's definitely not easy. Takes a good eye and a lot of checking. Make sure you have a quick comp if you're going to get into keying and effects.