Furcadia Framework For Third Party Programs, So EASY a caveman can do it! Options

[Squizzle]

Furcadia Framework makes RAD easier for third party developers. Developed in .NET it can be used with any .NET language (c#,vb.net,c++,boo,etc)


Features

• A easy class (NetProxy) to make your very own Proxy/Bot Program.
  • So easy a caveman can do it! NetProxy my_proxy = new NetProxy(6500); Then call my_proxy.Connect(); If you want to capture data then use the my_proxy.ClientData or my_proxy.ServerData.
• Creating your very own Pounce-like program with PounceConnection.
  • Easy as PounceConnection my_pounce = new PounceConnection("Friend","AnotherFriend","AndAnother",YourPopular"); Then calling my_pounce.Connect();
• Some extras like Furcadia.Util.Path gets the Furcadia directory and Furcadia.Util.Host gets the Furcadia server host.

Thank Yous!
Many thanks go out to Dream Dancer, Lothus Marque, Artex and DEP for providing your server protocol to nerds like me. (If I missed anyone let me know and I will add you asap.)

Project Page: http://furcadia.codeplex.com/

This post has been edited by Squizzle: Feb 28 2010, 05:53 PM

[Artex]

Speaking of paths, here's something I made for personal use in C#: Paths.cs

In theory, it should allow you to auto-detect the current Furcadia path (even if installed in a non-default location and even if localdir.ini changes are applied). Here's a tool that should test its operation: pathdiag.exe

You can change it to fit your needs if you see any use in it, or make one yourself, if it would help improve your project.

Good luck.

[Squizzle]

I made it open source that way anyone can contribute and if they have a contribution I'll gladly add it giving proper credit to them.

Edit: Researching this (Cross platform way of getting paths). Nevermind this line

On another note anyone here familiar with Mono Develop? I was trying to create a build package for other platforms to add it to the project but it kept giving me a "File not found." in red text at the bottom of the Package Output.

[Artex]

Linux per se doesn't have "My Documents". Distributions like Kubuntu seem to imitate something like that in their settings by adding these "Windows-like" folders in your home folder, but that doesn't mean that Ubuntu or other non-*buntu distros will have the same system going on.

Me - I wasn't making these files with other OSes in mind (and thus I boldly used a using Microsoft.Win32; statement in there) because as much as .NET and the guys at Mono try to bring all its features to other platforms, some of .NET's functionality will be a problem to implement on non-Windows OSes. If you can run .NET programs wrapped in wine (which is kinda layery already: Linux->wine->.NET runtime->app.exe) you might have it easier because wine has most of these paths supported (if not all of them) and that's where Furcadia itself runs, too. Otherwise, you'd probably need to simulate this stuff or rely strictly on localdir.ini...

Distro maintainers don't seem to be keen on having .NET support out-of-the-box yet, not until they get it straight with MS and their licensing. With that attitude, it will be a problem distributing .NET programs to Linux users - something that used to be a problem with Windows: Your small program with the little it does weighs a few kilobytes or so, and for that small program, a user needs to download almost a hundred megabytes (if not more) of .NET and install it on their PC! My fingers won't rise to require something like that just to run my program and thus, if you can't run the exe as you are, you probably shouldn't bother - for your own sake. That's why it kinda sucks making Python scripts for Windows and .NET applications for Linux - the user doesn't have the interpreter by default and the download size is unacceptable IMO. :/

[Hexi]

Distro maintainers don't seem to be keen on having .NET support out-of-the-box yet, not until they get it straight with MS and their licensing. With that attitude, it will be a problem distributing .NET programs to Linux users - something that used to be a problem with Windows: Your small program with the little it does weighs a few kilobytes or so, and for that small program, a user needs to download almost a hundred megabytes (if not more) of .NET and install it on their PC! My fingers won't rise to require something like that just to run my program and thus, if you can't run the exe as you are, you probably shouldn't bother - for your own sake. That's why it kinda sucks making Python scripts for Windows and .NET applications for Linux - the user doesn't have the interpreter by default and the download size is unacceptable IMO. :/

I concur, and this is part of why I have been reluctant to switch to the .NET way of doing things.

[Dream Dancer]

... a user needs to download almost a hundred megabytes (if not more) of .NET and install it on their PC!

Likewise and why I will probably never go dot net.

[Treeki]

That's why I always target .NET 2.0 for my apps. It's a leaner version that still includes everything possibly needed for Furc stuff. It's just a 23mb download for XP and previous, it even works on Win98 and Vista/7 users don't need to download anything extra.

[Squizzle]

http://www.hanselman.com/smallestdotnet/

The web download for .net 3.5 here .Net download is a one stop shop. You download it once its done.

[Kylix]

Having the .NET 2.0 framework installed is not an unreasonable expectation these days considering Vista ships with 3.0 and 7 ships with 3.5. That, and the non-service pack version of 2.0 is compatible with 98 and Me. Even the IT departments of some of the largest of companies are moving over to newer .NET technologies.

Besides legacy support or familiarity, I cannot think of one compelling reason to stick with VB6 anymore. The newer Visual Studio IDEs are very powerful and quick debugging tools, the JIT compiler keeps closing the gap between native and managed performance, and the security models are vastly updated. Plus, the .NET Framework itself provides a lot of functionality that you can't easily do in VB6 (ActiveX controls neglected) or .NET makes it much easier to work (see: registry, console, i/o, jagged arrays, etc, etc).

[Squizzle]

A new build in the SourceCode section. "Updated Net/PounceConnection.cs to be Asynchronous and continue until Kill() is called."

Now its more useful lol. OH and I finally figured out how to use TortiseSVN after a few tries

http://furcadia.codeplex.com/

@Artex: I would like to use your code but I am going to have to find out what differences there are with Linux Wine - Windows. I'm trying to make it work for all operating systems that can support Furcadia, no matter how much work that might involve.

How did Ghost Tiger do it? His client is suppose to be basically the same thing but on a different platform, right? If there is no registry to find the Furcadia path then what does Ghost Tiger use?

[Artex]

I'll try getting .NET on wine today and see what's going on there (if I can, never tried that before). The differences shouldn't matter that much, however. All in all, it's the same environment variables and registry keys, but with different paths.

20091030@0950 FST: Seems like there's no way in hell a regular user would get .NET to work on wine - it doesn't install out-of-the-box, so we're left with mono on Linux itself. Mono does seem to have special paths of its own from what I've seen with pathdiag.exe. Linux has no registry, so using the registry calls is pointless. That didn't, however, crash the app when I tried running it! So we might just get away with registry traversing, as long as we don't rely on it being available or accessible. I'll make a program to display all them special paths and see what is mapped to what on Linux. Could come in handy when going cross-platform.

But yeah, I also go Treeki's way when it comes to .NET, because I know that most Windows OSes today have at the very least .NET 2.0 installed on them and if I need to make an app for someone, I'll know they will most likely be able to run it out of the box. Mono already got to 2.0 as well, so in general, the app can also run on Linux unless I don't think cross-platform, but seeing that mono isn't available out-of-the-box, Linux support is something I'll most likely keep just for my own convenience, at least for now.

The concept of .NET is great in itself, and from what I've done with it vs. C++, it seems pretty fast, too. Java has a similar ring to it (and that's what .NET basically comes to try and replace), but it's plain slow, and I'm not sure if it's as flexible. I just hope that .NET will become cross-platform and widely supported rather than yet another Microsoft thing you have to have Windows in order to use. Either that, or have to read pages of license agreements and spend a week or two with a bunch of lawyers deciphering it just so MS doesn't go and threaten you and your projects when they consider them a threat to their business, or decide one day that you should be paying them per copy you release.

How did Ghost Tiger do it? His client is suppose to be basically the same thing but on a different platform, right? If there is no registry to find the Furcadia path then what does Ghost Tiger use?

Ghost Tiger doesn't really need to look for Furcadia installation folder, or adapt to the path structure of DEP's Furcadia because he has his own client - he can invent his own paths and use his own ways to find the install path, more suitable to OSX rather than original Furcadia's structure. He supports just the OSX platform for which he doesn't need to think about being cross-platform or anything non-OSX and non-Mac. Hell, he can make his own file formats and have a translation module for Furc's files in order to support them. You can supply binary data in TXT files, afterall, when you upload a dream. Can be used for "extra features" :P

[Artex]

Here's some Linux reference for ya:

Windows 7 x64 Path Reference

CODE

      ApplicationData -> C:\Users\IceDragon\AppData\Roaming
CommonApplicationData -> C:\ProgramData
   CommonProgramFiles -> C:\Program Files (x86)\Common Files
              Cookies -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\Cookies
              Desktop -> C:\Users\IceDragon\Desktop
     DesktopDirectory -> C:\Users\IceDragon\Desktop
            Favorites -> C:\Users\IceDragon\Favorites
              History -> C:\Users\IceDragon\AppData\Local\Microsoft\Windows\History
        InternetCache -> C:\Users\IceDragon\AppData\Local\Microsoft\Windows\Temporary Internet Files
LocalApplicationData -> C:\Users\IceDragon\AppData\Local
           MyComputer ->
          MyDocuments -> C:\Users\IceDragon\Documents
              MyMusic -> C:\Users\IceDragon\Music
           MyPictures -> C:\Users\IceDragon\Pictures
             Personal -> C:\Users\IceDragon\Documents
         ProgramFiles -> C:\Program Files (x86)
             Programs -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
               Recent -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\Recent
               SendTo -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\SendTo
            StartMenu -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\Start Menu
              Startup -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
               System -> C:\Windows\system32
            Templates -> C:\Users\IceDragon\AppData\Roaming\Microsoft\Windows\Templates

Kubuntu Path Reference (Jaunty, KDE 4.3.2)

CODE

           StartMenu ->
           Favorites ->
     ApplicationData -> /home/icedragon/.config
            Personal -> /home/icedragon
    DesktopDirectory -> /home/icedragon/Desktop
  CommonProgramFiles ->
             Startup ->
              SendTo ->
             Cookies ->
CommonApplicationData -> /usr/share
             MyMusic -> /home/icedragon/Music
              System ->
LocalApplicationData -> /home/icedragon/.local/share
             History ->
          MyPictures -> /home/icedragon/Pictures
         MyDocuments -> /home/icedragon
              Recent ->
       InternetCache ->
        ProgramFiles ->
           Templates ->
          MyComputer ->
             Desktop -> /home/icedragon/Desktop
            Programs ->

Keep in mind:

• /usr/share - can't be written to if you're not root (and trust me, in Linux, even the admin account doesn't have root privileges by default!)
• /home/icedragon/Music, Pictures, Desktop - probably pre-set in mono, this is consistent with default KDE settings, but not connected to them: if you change KDE settings, this doesn't change in mono! It might be the same with other distros.
• Empty paths are most likely empty strings, so they're safe.

Now to see what happens with the registry... :P

[Hexi]

why not just store the paths into an ini file?

[Artex]

Furc relies on Windows to tell it where these paths are in the system it's currently installed on, be it Wine, WinXP, Vista, Win7 or some other flavor. By storing them in a file, your app will no longer adapt to the more "exotic" cases or future versions of Windows which may have an altered filesystem structure.

If you're on an x64 system and you have an x86 application, Windows will automatically tell you that you should use "Program Files (x86)" for your application to avoid mixing up with 64bit apps. You can also alter the path of the My Documents folder in the system to something else (D:\ for instance). If you'd make My Documents static in the INI file, you'd end up storing or retrieving files from a wrong location.

It just gives you more responsibility than you'd rather have: Instead of relying on the system to tell you where it's best to store certain files, you have to know it by yourself and be aware of all the possible Windows flavors and scenarios like path changes from their defaults..

It's like telling windows "Handle URL <url>" and let it launch your favorite browser or program to handle a URL or a file depending on its type. You can store in the INI file which programs should it look for and launch for certain stuff, but why not let the OS do the work for you? :P

[Definated]

How did Ghost Tiger do it? His client is suppose to be basically the same thing but on a different platform, right? If there is no registry to find the Furcadia path then what does Ghost Tiger use?

Like Artex said, GT made his own client. For instance, aside from the file extensions Furcadia uses (ds, map, fox, ...), it also uses some of its own file types. Like FSX -> a deprecated mFurc patch format.

And for reference, paths are done much differently than Furc uses them.

/Users/USER/Library/Application Support/mFurc/
- / - Character INI Files (Uses a modified format for mFurc.), Contact List Settings
- /Bookmarks/ - Bookmarked dreams
- /Dreams/ - Downloaded dreams (from the fileserver)
- /Logs/ - Log files, Whisper Log Files
- /Maps/ - Directory provided to save player created dreams to.
- /Patches/ - Directory provided to save player created patches to.
- /Portraits/ - Portrait cache

/Library/Application Support/mFurc/
- /Maps/ - Default maps
- /Patches/ - Default patches

[Dream Dancer]

And as a case in point of altering paths, every machine I set up has the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList set to the root of a second hard drive. So running %userprofile% on them usually gets you like "E:\{profile-name}\".

[Artex]

Now to see what happens with the registry... :P

And so I've seen. Looks like registry emulation is supported on mono, but you'd have to store something in it before retrieving it. There is no registry on Linux per se, so there's nothing to access unless you put something in there.

Accessing the registry in an attempt to retrieve Furcadia's path (the way you used in Utils.cs) produces the following exception:

CODE

icedragon@ruth:~$ mono PathDump.exe

Unhandled Exception: System.Security.SecurityException: No access to the given key
  at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir) [0x00000]
  at Microsoft.Win32.KeyHandler.Lookup (Microsoft.Win32.RegistryKey rkey, Boolean createNonExisting) [0x00000]
  at Microsoft.Win32.UnixRegistryApi.OpenSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable) [0x00000]
  at Microsoft.Win32.RegistryKey.OpenSubKey (System.String name, Boolean writable) [0x00000]
  at (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey:OpenSubKey (string,bool)
  at Microsoft.Win32.Registry.ToKey (System.String keyName, Boolean setting) [0x00000]
  at Microsoft.Win32.Registry.GetValue (System.String keyName, System.String valueName, System.Object defaultValue) [0x00000]
  at PathDump.Program.Main (System.String[] args) [0x00000]

So basically, as long as you try{} the registry check, it should be go painlessly on Linux - you'd just assume that your registry entries didn't exist and go on with the program.

This can be a useful read if you're interested in app portability and compatibility with non-Windows OSes: http://mono-project.com/Guidelines:Application_Portability

HTH

[Squizzle]

@Artex: You are invaluable. Thank you very much for the information. The registry check is wrapped in a try catch. Don't know why that SecurityException wasn't caught.

And I wanted to make a note to everyone that has downloaded the source that the SourceControl builds are more up-to-date and if you are using the source code and want the latest build check for it there.

Anyone have any information on how Ghost Tiger stores the his client's path? Is it through a similar localdir.ini that Furcadia (Windows) uses?

[Definated]

Anyone have any information on how Ghost Tiger stores the his client's path? Is it through a similar localdir.ini that Furcadia (Windows) uses?

I believe the paths are hardcoded (since the mFurc installer CREATES said paths). There is no ability to change WHERE the program and support files are installed, just the disk to install them on. The paths chosen are based off Apple "recommended" developer locations. See the following document (in the Passwords section) for information on where developers SHOULD put folders.

http://developer.apple.com/tools/installerpolicy.html

[Squizzle]

Alright glad I finally got that out of the way!

BUT FIRST.

I have to give credit where it is absolutely necessary.

Credits for this release go to Kylix and Artex. Kylix for his code on Fox format and Artex for his Paths class.

Get It!

[Now to the project I've been wanting to get to for quite some time! If you do not know what I'm talking about see the TODO.

Wow.. 339 project views? There can't be that many Third Party Developers for Furcadia? Can there?]