Zurich System

Well I deleted the original thread by accident :o

Objective:
Stage 1. Design an executable program that will serve to store economic information collected by the reeves.

Stage 2. The system will collect information automatically.

Stage 3. The system will perform predictions and provide logistics information.

Those are the three stages that I hope to bring the program through.
The program will be a downloadable windows client that guild members (and hopefully others) can install on their computers. The client will connect to a security systems on a server. The security system will be the middle man between the client and the information database and it will prevent private information from being given to just anyone. This program will be an executable and not a web-application since at stage 2 it must be able to self-collect information. I've provided a diagram to better explain how it works.


The program can be divided into 6 modules.
- Data classes
- Communication Protocol (both unix and windows)
- Security server
- Database
- Win32 GUI
- Engine

It will also have 2 additional modules for the later stages
- Prediction methods and Logistics
- Automated Information Collection

Provided with the project for now are the rough draft blue prints for the Data classes and a simple GUI flow diagram. They are in both picture and DIA format. DIA is a multi-purpose diagram creation tool. It will mostly be used to simply draw UML diagrams and blue prints. You must install GTK to be able to use DIA. DIA and GTK are too large to upload to the system so I will provide them to anyone who feels like contacting me on msn (Norvisssion@hotmail.com) or aim (Thirlan).

For those of you that are interested, here is what I need right now. I need someone that knows c\c++ (with Object oriented design) or knows how to program a database. You have to be able to stay organized and follow the blue prints I create and if possible create blue prints yourself. Further assistance with different aspects will be required later and will be posted at such a time.

p.s. Keep checking the first post of this thread since I will write the updates here rather than make new posts.

Question: "Does the program interface into the darkfall servers and will they consider this to be an illegal program" - Father Merrin

Answer: It doesn't interface into the darkfall servers. It interfaces into the Darkfall client and I hope they don't find it to be a hack. All it would be doing is reading logs/memory addresses. It isn't modifying them. At first the data would be collected manually through the reeves/volunteers and then automatically.

Question: "Can the program be done without actually having DF yet?" -Dafur

Answer: The answer is yes and no. Yes because we can create what we know will be in game and no because we can't perform stages 2 and 3 before we know the program and minor details. Stage 1 is an overall system and deals with solid facts. For starters we know there will be players (duh), each player will have an x,y,z coordinate in the darkfall world. We know there will be clan stones and that they are static. We know that there will be a structure in game called "guilds" and we know there will be money. Based on these simple things, we know that we can try and gather data on guilds, players and their money. That is what stage 1 will accomplish.

Nira, your help will be greatly appreciated. You can develop the security server. It is what interfaces with the database and controls what the user can and cannot see/modify based on their priviliges. I'm not sure if I want to use TCP or UDP, but I will create a small package that will control our communication protocol (i.e. how everything is parsed, framed and encrypted). You should use that so that we stay consistent. You however have to design your own network system since it will have to work on a UNIX server, whereas my network system will be on windows.

So to say it one more time for clarification. There will be three communication modules. The windows one, the unix one and the communication protocol. You will design the unix communication systems and the security server. Provide blue prints before you create it if possible and give me a run down of how it will work. This is to make sure we're both on the same page.

I'm going to quickly create a blue print of the communication protocol for windows so that you have an idea of what I'm looking for.

oh dear lord. it's back... again!

I can't attach files with edit so unfortunately I have to create more posts.
Here's the simple blue print for the network. It will obviously change later when we get to coding.

The WindowsNetwork works as follows. The first time you create a class (and only the first time) it will also create a new thread. This thread will be the brains of the system and will send and receive messages. The class you create will be an interface to the thread through the static queues you see in the blueprints. The thread will take incoming messages and unparse them then put them in receiveQueue. The instance of the WindowsNetwork class has two functions, send and receive. When you do a.send("bla") the send function will add it to the sendQueue (which is static). The thread will read this message from the queue and send it to the server. The server will send back the message, which the thread will receive and the thread will put it in receiveQueue. Now here's the beauty of this system.

WindowsNetwork a = new WindowsNetwork();
WindowsNetwork b = new WindowsNetwork();
WindowsNetwork c = new WindowsNetwork();

a.send("blah");
b.send("blah1");
c.send("blah2");
char *temp1 = a.receive();
char *temp2 = b.receive();
char *temp3 = c.receive();

When a is created the thread is created as well. When b and c is created the thread already exists so no more threads are created. A has instance id 0, b has instance id 1 and c has instance id 2. When a.send("blah") is called it sends "blah" to sendQueue[0][] because A has id 0, b.send("blah") sends it to sendQueue[1][]. The thread grabs these messages see which instances added it to the queue and sends the message to the server. The server responds and the thread then appends the incoming messages to receiveQueue[0][] for a, receiveQueue[1][] for b and receiveQueue[2][] for c.
So no matter how many instances of WindowsNetwork you create there will only be one main network thread driving everything and if you are running a multi-threaded program then each thread can have it's own instance of the network class and each thread will receive messages only pertaining to it.

UPDATE: Saturday, October 7th, 2006

-Corrected an error in the ClientSideGEneralizedFlow diagram. Deleted the connection between the loan menu and the map menu.

-Added "Zurich_" to all the packages for naming consistency

-Renamed Communications to Zurich_Comm

-Added security variables to the appropriate datatypes and added the appropriate methods for each

-Created the basic skeleton for the Zurich_GUI package. More will arrive as I perform more R&D

-Reorganized the Zurich_data package so that it isn't as confusing

-Added forgotten methods and variables to Loan, Player and Guild class. Such as the fact that a player belongs to a guild.

-Added the Key class to the Zurich Data system. Key will serve as the security protocol for protecting the infromation.

-Made massive revisions to the Zurich_Data class. There were unforseen issues with the memory storage and security measures.
Example: A player class had a loan class in it and a loan class had a player class in it. This circular datastructuring would result in classes with infinite size since when you created player B and his loan A, loan A would then create player B, which would then create loan A...
A simple pointer doesn't solve the problem since how do you store a pointer in a database ^_- You don't because it's a memory address and the memory addresses are different for each client. This revision will affect the engine, which will in turn affect the server, which will no longer just be a security server but will also perform all the numerical computations upon receiving data.

-Data class has not been finished yet. Modifications will be finished tomorrow.

UPDATE: Thursday, October 19th, 2006

- The Zurich_Data package became so complex that it the confusion generated simply by looking at it was too much. The package has thus been seperated into four parts. It is still the same package but instead each picture shows specific details. Zurich_Data just shows all the classes with no relations. Zurich_Data_Inheritance shows who is inheriting from what. Zurich_Data_Aggregation shows who is composed of who. Zurich_Data_Complete shows everything

- The Data package has now been completed with respect to all the information that is currently available. Coding will now begin on this package.

- Reversed the inheritance arrows in Zurich_GUI (whoops!)

- Added some encryption/decryption methods to Zurich_Comm

I'd upload the new blue prints but apparently my upload stash is limited to carrying only 1 meg of data. Fishbarrel could you increase that to say 10 megs?

php.ini (which we don't have access to on this server) is limiting the maximum allowable PHP upload to 2MB. I could change the vBulletin settings, but it won't make a difference. Use FTP or something I guess.

This is a *very old* thread - but I'll comment anyway .

Wouldn't it be simpler to develop a web application and have Reeves manually enter Data, then to develop something that may need to change with each patch and risk being detected as an illegal third party utility?

A thing like this can be used for so much more then just keeping track of tax money. It's pretty neat to get statistics from the whole guild all at once.

Also manually gathering all the data this application could collect is pretty much impossible task ...

This project is still only in a blueprint form and has changed considerably from what you can read here. I have recently become highly proficient in .NET and so the project can now be made into a webpage as well as with an exe extractor. Yet there are issues with the exe extractor that I have discovered recently when studying it. Due to this difficulty and from an engineering stand point it will probably first be designed for manual input and if feasible, automated collection will be included as well. Hence in the failure of one there will always be a back up. I have many clever ideas for increasing the amount of manual collection methods. Anti-information corruption and sabotage techniques have also been thought of. I mean I have spent almost an entire year thinking about this program.

This project will, however, stay as a thought for a while longer as I am currently working on other projects. Fortunately, delaying this project has proved highly beneficial, giving me time to contemplate the project and to see if DFO will provide some form of support in collecting data. There is also the fact that Brando may handle this, though he uses php, which means that a majority of the workload would be on Brando's shoulders. If Brando becomes too busy or does not feel up to the task then chances are I will handle it, seeing how my in game position will be little more than paper pushing :p and I will probably keep it that way. Too few people are interested in "Logistics, the role playing game" and it is such an important factor to these empire games too.