rilex

You're too awesome. Thanks hunuza!

No, not PHP, .NET (C# or VB.NET). Unfortunately I can't find any real documentation of pack/unpack from php.net as to what it is actually doing (sure, convert to binary string, but what type, etc. -- .NET has many types of binary strings), so I wanted to find out how Mangos was doing it instead.

Okay, how does it decode the values...I suppose that is what I'm getting after. How does it take the value I have provided above and convert that into a float? Obviously we can't just float that value.

Can someone explain the steps GetFloatValue is taking, e.g.: 2[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]22[/color][/size]2[/color][/size][/size]

Bummer, thanks. If I knew C++, I'd try exposing it...ah well

Yeah, I mean something like ScriptDev2 where you could hook into binary to pull that information.

Is there any method for an external application to pull the revision number out of the Mangos binary (specifically Windows, here)?

I'm unable to read the entire text of the commit. It bleeds underneath the right hand cell where the hash of the commit is. Also, the gadget window is larger than it needs to be. Can you resize to fit just the number of entries (i.e. by default, 3)? Seems unnecessarily large. A close button on the commit window would be nice (even though you can click away to close).

Please be aware that realmd and mangosd are, by default, have the LAA flag set, with no known issues as a result of doing so.

No, but each executable can be multithreaded.

If the process is 64bit (like Mangos can be), 8TB. More memory than you'll have installed for a little while.

No, that is not true.

Ah okay, it wasn't clear from your original post that you wanted help in something. In my opinion, you should just have said "hey, I want to code a multi-process core, anyone want to help?". It would have lead to less confusion and more appropriate responses to the outcome you're looking for (help on this project).

At least with a normal American infliction, the way it is phrased would be insulting. I suppose we do have to account for the non-native English speakers

If your plan was just going to be 'insult everyone', why did you bother asking the community what they would like to see?

Why would multithreading be "big" but not multiprocessing/clustering support?

With AWE you can, but the programming for it is complex.

Which is why focusing on multithreading would be more advantegous to the user base than focusing on clustering support. Focus on the many. I think Derex pointed out the disadvantages fairly well, although I still don't understand why a multithreaded + multiprocess application could not be created, and why it requires multiple processes to make it so (leverage existing OS clustering support, perhaps?). Yes, you do have to enable /3GB, but I've been running it that way for some time now (I submitted the original LAA flag patch).

No one here suggested that you tell the system which thread to run on which core/CPU. My point is that multithreading things like maps is FAR more valuable than providing cluster support. While I do have a ton of DL360 G2s available, I don't /really/ need a cluster. I'd prefer to have better multithreading support. No, AWE. AWE allows PPros or higher to address up to 64GB PAS when using the NT kernel. Not for Mangos, which currently has the largeaddressaware flag enabled. You have a point for Term Servs, but again, not for Mangos which is what this thread is about. Also, remember that OSes, like OS X/Darwin, provide a 4/4 split. It causes TLB trashing more-so than a system with a 2/2 or 3/2 split, but it does exist.

While this is true, you do not get as good of a performance improvement out of it as you would if the devs put work into optimizing the threading. And, of course, various components (e.g. maps) run on a single thread that could be split out into multiple threads. That is what AWE is for (and applications don't address RAM, they address virtual address space), and on some platforms they can use all 4GB VAS.

Seems like an odd limitation with Mangos. I'd vote multithreaded. I would think there are more users with 2+ cores vs 2+ machines.

When it is ready

Pictures are up at: http://www.codeplex.com/micromanager/Wiki/View.aspx?title=Project%20Screen%20Captures This isn't all of the site content, but it is most of the key points.

Screens are OK, I'll post some up on the CodePlex site when I get a few minutes. But yes, actually using it versus just seeing screens would be the way to go. I'd also suggest using code from SVN instead of the current release (0.71) as it has a lot of features which have changed. Which, unfortunately, means I don't have good directions for them right now. Have to work that, too.

µManager for MaNGOS 0.8.6 has been released! Downloads: * 0.8.6 Release Highlights of 0.8.6: * Supports up to MaNGOS revision 9692 (may support higher revisions, this is dependent on any changes made to the database structure by the MaNGOS team). Make sure to have Client Patch Level 3.3.0 selected in Setup.aspx (even if the Client Patch is actually higher, such as 3.3.3a). * Visual Studio 2010 support * .NET 4.0 Required * Vastly improved security model, utilizing the MembershipProvider to enumerate user's roles and properties, instead of saving them in the user's Session State which was unreliable. * Many misc. bug fixes Software Requirements: * .NET 4.0 * Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Vista SP1, Windows 7 (x86 or x64) * MaNGOS 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0 * Adobe Flash Policy Server (setup file included in Nauplius.MaNGOS.Setup folder) * MySQL 5 * MicroManager database (SQL file located in Nauplius.MaNGOS.Setup folder) Documentation: * Project Documentation Forums for Support: * µManager for MaNGOS Codeplex Discussion * MaNGOS Support Forums Screen Shots: * 0.8.6 Screen Captures About: µManager for MaNGOS is an ASP.NET front-end written in VB.NET to manage a MaNGOS server. µManager for MaNGOS is a port of Minimanager for Mangos. The goal of this project is to maintain feature-parity with Minimanager, but target some Windows-specific features. Source Repositories: * TFS (recommended): * Server Name: tfs05.codeplex.com * Port number: 443 * Protocol: https * Project Name: micromanager * SVN Current Developer Needs: * Translators! Translation is quite easy and does not require developer experience. See this guide for documentation. * CSS/Javascript/layout experience is needed. * Anyone with VB.NET WebForms experience is always welcome to join!