Flakes Construction Yard

YSFlight addon development, questions, tutorials, & more!
User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Thu Nov 23, 2017 4:19 am

Image

That refactor was more difficult than it looked, but got there in the end.

----

So it turns out you can do some neat stuff with windows command line:

Code: Select all

tasklist | findstr fsmaino
tasklist | findstr fsmaindx
tasklist | findstr ysflight32_gl1
tasklist | findstr ysflight32_gl2
tasklist | findstr ysflight32_d3d9
Pipe each process id into:

Code: Select all

netstat -aon | findstr xxxx
To find remote addresses that each YSFlight program is connected to, if it is connected.

Plug this up to a simple windows service and an installer/uninstaller for that and I link this to an authentication form for YSFHQ.

I can send "automatic logins" packets to any YSFlight server, from any YS version. No need to pipe through a tunnel, slowing your game down, bcause all I really needed in the first place was the external IP you've connected to.

You'd literally just start YSF and connect to your favourite server, set and forget. No funky logins on the server side. Choose any username you want, and any OpenYS enabled server will recognise you when you login by your YSFHQ username.

That's something to get excited about for the future.

(Extended protocal functions and the like that is client sided will still need to go through a tunnel service though.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Fri Nov 24, 2017 7:47 am

Image

Built an authenticator...

Image

Also built a detector for seeing which servers you are connected to. Works for all YSFlight executable types
(so long as you don't rename the exe)...

Only thing I'd need to do to finish that up is some crash wrappers, a place to store and load the username and password, and then link with a UDP packet to the host with your YSFHQ ID.

If the host happens to be running my new version of OYS, they'll automattically log you in.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Thu Nov 30, 2017 11:31 am

Update: Working on the skeleton and basic functions for Servers today. Those following the OfficerFlake Library on GitHub will be able to grab my source at all times I commit a change, which is each day I work on the code.

Implemented a class for Connections, which can handle TCP/IP and UDP input, will be driven by events. Copied the old, stable code from OYS for the TCP/IP side. UDP, though I'm using static methods, needs to be refactored into its own class. Issue there is many client can reference the UDP receiver and mess the connection up: 1 udp client recieves all the messages to all clients on the server, where as with TCP one client has one socket that recieves the messages just for it.

Implemented basic GenericPacket, before I re-do the packets from OYS. Can safely read data that doesn't exist by fudging zero's. Can set data that doesn't exist in the array by appending data to the array. Returning the correct values for all common data types: Bool (a bit as part of a byte), Byte, SByte, Int16, UInt16, Int32, UInt32, Single (floating point), String. Further specialisation will be done in the packet itself.

Created a simple test packet of type 00 and edited the data a bit to confirm all is working and not broken. Used weird and funky numbers and other ways of manipulating data to confirm that the program won't crash in future based on the possible inputs of each data type.

I'll copy across the packet definitions I have from OYS starting tomorrow and we'll see if I can have the first working server for OYS 2.0 in the next few days.

No settings yet. No database to store data, it'll just be very bare bones. At this stage, I'm near refactoring old-code point so the production should hopefully accelerate from here.

Also to note: String in/out is being handled as UTF8 instead of ASCII, so this should stop future crashes due to weird symbols on places like Discord. In fact, I'm using a StreamReader and getting the encoding detected from that, so if the encoding is different, that I should be able to pick that up correctly too.

With each new version of OYS, I improve as a programmer and make for a cleaner, more bug free program. Here's hoping the new code will be suitable for extended server use! Fingers crossed.

Code: Select all

223107 <OpenYS Console> TESTING BOOLEAN:
223107 <OpenYS Console> ----Current Value: False
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING BOOLEAN TO TRUE:
223107 <OpenYS Console> ----Current Value: True
223107 <OpenYS Console> ----Current Data: 10
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING BYTE:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING BYTE TO 127:
223107 <OpenYS Console> ----Current Value: 127
223107 <OpenYS Console> ----Current Data: 7F
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING SBYTE:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING SBYTE TO -127:
223107 <OpenYS Console> ----Current Value: -127
223107 <OpenYS Console> ----Current Data: 81
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING INT16:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING INT16 TO -1024:
223107 <OpenYS Console> ----Current Value: -1024
223107 <OpenYS Console> ----Current Data: 00-FC
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING UINT16:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING UINT16 TO 32767:
223107 <OpenYS Console> ----Current Value: 32767
223107 <OpenYS Console> ----Current Data: FF-7F
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING INT32:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING INT32 TO -1024:
223107 <OpenYS Console> ----Current Value: -1024
223107 <OpenYS Console> ----Current Data: 00-FC-FF-FF
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING UINT32:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING UINT32 TO 32767:
223107 <OpenYS Console> ----Current Value: 32767
223107 <OpenYS Console> ----Current Data: FF-7F-00-00
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING SINGLE:
223107 <OpenYS Console> ----Current Value: 0
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING SINGLE TO -1024.50:
223107 <OpenYS Console> ----Current Value: -1024.5
223107 <OpenYS Console> ----Current Data: 00-10-80-C4
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> TESTING STRING:
223107 <OpenYS Console> ----Current Value: 
223107 <OpenYS Console> ----Current Data: 
223107 <OpenYS Console> CHANING STRING TO "0123456789ABCDEF$$$$" (Limit 16 Char)
                        :
223107 <OpenYS Console> ----Current Value: 0123456789ABCDEF
223107 <OpenYS Console> ----Current Data: 30-31-32-33-34-35-36-37-38-39-41-42-43
                        -44-45-46
223107 <OpenYS Console> ----Clearing Data....
223107 <OpenYS Console> All Tests Successful

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Mon Dec 04, 2017 5:47 am

Much has happened since my last update:

Now loading all Aircraft, Grounds, and Scenerys from default YSFlight Folder.
Now have a basic barebones Server object that can accept TCP/IP clients, and UDP messages and pass them to the correct clients.

The only thing that the server is missing now is a processor to handle incoming packets. That's just a refactor of old OYS code, so shouldn't take more than one day.

One day until OYS 2.0 alpha is ready? Let's hope...

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Tue Dec 05, 2017 7:35 am

Image

Ahh yes. I see you know your Netcode well.

I can now send and receive data and messages to connected clients.
I can now wait for specific packets, by defining specific parameters of the target packets I am after.
Packet send and receive is once again async with callbacks and invokations.
The login method is already much cleaner than it used to be.

There's a LOT of processing code to refactor, so I might have been optimistic. I'm also going to be busy for the coming week, so it might be another fortnight or so until this is done but it should be worth the wait.

Tech specs:

Can do cool stuff like:

Code: Select all

thisConnection.SendMessage("Sending you the Version Packet");

Type_29_NetcodeVersion packetNetcodeVersion = new Type_29_NetcodeVersion();
packetNetcodeVersion.Version = 20110207;

thisConnection.Send(packetNetcodeVersion);

////

PacketWaiter thisWaiter = new PacketWaiter(6); //Get an acknowledgement
thisWaiter.Require(0, (Int32)9); //which has an Int32 at data position 0 equal to 9.
thisWaiter.Desire(4,(Int32)10); //Example, optionally require this.
thisWaiter.Desire(4,(Int32)11); //Example, can choose between any desire option, and will match so long as one or more conditions are met.

bool result = thisConnection.GetResponseOrResend(thisWaiter, packetNetcodeVersion); //wait for response, if we don't get it, try to resend until we get a reply. Give up after three tries.
bool result2 = PacketWaiter.WaitUntilRecieved(int timeout). //Blocks until a packet that meets the given criteria is received.

Type_06_Acknowledge thisAcknowledgent = thisWaiter.RecievedPacket;

////
So already the code for waiting for data is quite flexible. By the way, none of this is blocking. So if a packet comes in that I don't want to look at, it's handled normally. No threads, no mess, just Async callbacks.

More to come in the coming days or weeks. Stay tuned!

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Tue Dec 05, 2017 9:42 am

Can now login to the server but much further to go before I can join flight. I'm currently trying to add the ground objects to the server and failing miserably.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Wed Dec 06, 2017 5:30 am

Progress:

Image

Data is occasionally not sent, and connections are occasionally not being accepted/processed, so I'll be inspecting that closer over coming days.

Object position isn't being set correctly, though the world loading is reporting no issues. I'll have to get down closer to the code and inspect.

We've got a lot of little things to iron out now before I can build any higher.

EDIT: Apparantly YSF throws a hissy fit if the datasize if the packet is not at least what YSF needs. This is why Fields would load at funny angles sometimes. If there was an exception, the packet size would be less than 60 and YSFlight itself would throw an exception trying to access that data. Of course, I don't get to see there was an error because throwing errors back to the user would just be logical (Thanks Soji). And the errors we do get (which should really just be a warning) block the UI. Why am I coding for this mess of a game again?

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Thu Dec 07, 2017 1:49 pm

Quick update: I've now started using Async/Await/Task library built into C# 5.0 and .Net 4.5+. Sorry WindowsXP, You've been deprecated for a few years by Microsoft now and I can't justify supporting you any longer. If you use WindowsXP and don't have computer AIDS, I'm impressed.

The data I/O for sockets and other net data is now very very clean and is not having any errors. All errors are antiticpated and handled with appropriate Try/Catch for the possible errors each method could return.

Clients disconnect gracefully from the server, and their objects are confirmed collected by the .Net Garbage Collector.

It would appear the Connection class is now stable for long term use.

Also decided that there really should be only ONE console, codewise for the program so I made a static-object wrapper for that. Can now use "Console.AddDebugMessage" or "Console.AddWarningMessage" etc anywhere in the code so long as I link the delegate in the executable. I might do a bit more work to have Debug in a seperate, optional console window. This will be quite verbose.

I am also intending on adding a per Connection packet logger, that can be tied with a Form for easy inspection of YSFlight Netcode when operating in proxy mode. This will allow me to confirm packet signatures much faster, and inspect bugs and solve quicker.

At this stage, I can load the world, all aircraft and ground objects from the lists. Some bugs in world/metadata loading but I will refactor that all out, I've been making good progress so far. Grounds are spawning in the wrong location but I've made a simple FLD/STP/YFS set to test just a few objects in various positions. I will use this map to confirm my code is working correctly. This is a much better idea than just going gung-ho on random maps and praying for the best - this way, I can CONFIRM the code is working for certain scenraiors. By the way, The world/metadata loading will have debug information attached as well, I've already linked most of it to a master debug list but I should like to seperate them into individual debug lists before it's all done.

Road map from here: Test and confirm Metadata/World loading is bug free. => Develop a simple Proxy Server to run between YSF Vanilla Server and YSF Client => Make a quick UI to read the data for a specific client and show that in the Packet Sniffer UI. => Fix Bugs in Ground Object Population on YSF Servers (Location???) => Finish mapping more packets to enable players to send messages and join flight.

It's a long path ahead but it's going quite well. Stay tuned!

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Fri Dec 08, 2017 2:14 am

Fixed world loading. I wasn't comparing the lines in the file as UpperCaseInvarient, so child scenerys were'nt being processed. Fixed that for everything Loading related.

Image

----

Can now send ChatMessages, Notifications for users joining and leaving the server.

User avatar
Neocon
First Class Membership
First Class Membership
Posts: 3695
Joined: Wed Oct 19, 2011 5:01 am
Favorite Aircraft: Baron 58
Location: Tennessee
OS: Win Vista
Has thanked: 1498 times
Been thanked: 1620 times
Contact:

Re: Flakes Construction Yard

Post by Neocon » Fri Dec 08, 2017 4:56 am

You're a wizard, Flake!

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Fri Dec 15, 2017 12:16 pm

I moved house recently, so I've had a busy week.

Back at it, reworked the old Settings from OYS 1.0 into the new program. Improved a great deal of it by using Generics (that I now understand how to use!)

Settings can now take Units of Measurement as parameters. This will be very useful when settings things such as times or speeds.

Reworked a lot of the CommandFile class so that it's a better abstract class to inherit from: Can get the command, and parameters easier, and can resize the parameters easier. All this is tied with smart encapsulation to make the class easy to use from the outside.

I/O of files improved - now reads the file to an array on load, holds that array for any line reading/writing operations, and will only save when calling the save function. Long story short, disk usage is about to go way down.

Going to rewrite all the settings to be a bit more logically organised from here, then I'm going to create a debug window and resume coding the server side.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Sat Dec 16, 2017 9:04 am

Image
Another days work done.

Debug console is complete, and I can control if I want to see Crashes, Warnings etc. in it. Will be very useful for stepping through later when I need more information.

Reworked a lot of the File I/O classes and also reworked a bit of the Units of Measurement to be more concise. Lengths are now called Distances, Added a whole load of time handling funtions so I can store timespans and dates in setting files later.

I have moved CommandFile to the IO class instead of being a part of the YS class. I'm going to use that base class for the settings and databases. FYI, A command file defines a text file where each line starts with a command, then is followed by the parameters. Eg: IDENTIFY "F-16_FIGHTINGFALCON" would be a command. So would SETTINGS.OPENYS.LOADGROUNDS TRUE.

I've re-organise the settings file now.

Also I worked out how to load the PDB files into the program when I remote-load the required DLL's to run the program from the libraries folder. The documentation is terrible. What was happening in old Versions of YS was I was importing the dll but not the symbol (pdb) files. So then when an exception did occur, it would sometimes be too late to load the symbols, so when the program DID load the symbols after crash, it would be loaded for the wrong environment space at the time, saying that the error occured at Line 0, Column 0. Hopefully I can avoid that from now on.

I'll take the time to clean up over the next day to make sure I didn't miss anything important and it all looks uniform and clean.

That little menu-icon on the Debug Console can be clicked and it shows a context window which allows to choose the messages to be seen. I'll use that soon for the actual Console to control what messages are seen there.

Got a strong stable base to build on now. Time to start filling in the loose ends I've left behind.

Until the next update, here's a project dependency diagram and some statistics. There's 9465 lines of code so far, quite a lot! :S
Image
Image
EDIT: Project dependency tree is starting to get confusing. Going to identify all the key areas of the program and the layers at which they interact, and how to simplify all this. For example, FileIO shouldn't depend on Colors, likewise, Everything should be able to use a link to the debugger. Will sort this out as a priority, I have it mostly organise and once it's organised it's really just a quick copy-paste-rename refactor.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Mon Dec 18, 2017 12:32 am

So I started working on interfaces to solve project dependency issues.

interfaces always confused me. I could define them, work with them, but I never really understood why I would do that, if I could just use the implementation at a higher level instead.

The answer is to avoid complicated project dependencies.

See if you look at that dependency tree, It's quite complicated.

For example, Server depends on Connection depends on Packets depends on...

But with interfaces I could do:

Server depends on Interfaces.
Connection depends on Interfaces.
Packets depends on Interfaces...

And so on.

The purpose of implementing interfaces is that I can build the program structure quickly, then fill in the implementations when I am done with that.

Better yet, any class that implements an interface can rapidly "auto-fill" the interface requirements with NotImplementedExceptions. If I tie up an exception handling module at the program base-level (no dependencies) also, I can safely catch all parts of the program I haven't implemented, yet I can have the structure of the program fully defined. No more chasing my tail.

So that's what I'm working on now: I'm just defining the entire program structure in interfaces, then wrapping everything I've done so far around the interfaces.

I don't really need to change how anything works per say, just make it reference the interface.

Example:

Code: Select all

//Project: Interfaces
public interface IConsole
{
    void AddUserMessage(IUser user, string message);
    void AddInformationMessage(string message);
}

//Project: ConsoleIO
public static class Console
{
	private IConsole console;
	public void LinkConsole(IConsole console)
	{
		this.console = console
	}
	
	public void AddUserMessage(IUser user, string message)
	{
		if (console == null) throw new NotImplementedException();
		console.AddUserMessage(user, message);
	}
	public void AddInformationMessage(string message)
	{
        	if (console == null) throw new NotImplementedException();
		console.AddUserMessage(user, message);
	}
}
//Project: ConsoleUI
public class ConsoleUI : IConsole
{
        public void AddUserMessage(IUser user, string message)
	{
                //Do UI Stuff.
	}
	public void AddInformationMessage(string message)
	{
        	//Do UI Stuff.
	}
}

//Project: Executables
public class Program
{
        public static void Main(string[] args)
        {
                Console.LinkConsole(new ConsoleUI);
                Console.AddInformationMessage("This would show up in the UI!");
        }
}
Coded entirely by hand just then. Easy peasy.

What's great is now I could call from the User Project:

Code: Select all

IGroup group = someGroup;
AddToGroup(group);
while also calling from the Group Project:

Code: Select all

List<IUser> members;
foreach(IUser thisMember in members)
{
        thisMember.SendMessage("Hi!");
}
I couldn't do that before due to project circular dependency. I can make User reference Group, but if I do that, Group can't reference User. But I can do it now because User doesn't depend on Group, and Group doesn't depend on User. They both just reference the same project Interfaces where all the program structure is defined. User doesn't need to know anything about how Group works, besides the method signatures. Vice versa for the Group knowing anything about the User. This makes the program much more flexible, as from the Group, I can get a list of all the Users in that group, and for a User, I can get a list of all the Groups they are in. Stuff like that.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Thu Dec 21, 2017 10:16 am

Doing lots of work behind the scenes on interfaces still. I've almost finished all that.

Now I'm linking up the DAT file definitions to the interface, which required a re-write of the IMO terrible coding I did before.

Now DAT files properties extend CommandFile.Line so each property is like working with the DAT file directly. If I change a value in the DAT, the line can be automatically updated. When I'm done, I can just write all the DAT file properties to strings and that would give me the string that should be saved in the DAT. That's going to be hella useful when I start to enforce DAT file obedience on servers.

DAT interfaces is as simple as I can get it right now using Generics. I've made it so a DAT property can be defined by 8 different arguments, but if I need more I can always extend an interface for that easy peasy.

Now I'm writing a property like: EXCAMERA : IDAT_3_Properties<String, IPoint3, IOrientation3>. It'll be a long road of editing and fixing all the dat definitions as I go back over sample DAT files in the YSF folder and the entire DAT definitions.

Maybe I might finish this part tomorrow.

But yes, implementing the interfaces into the classes is going quite well. Once I'm all done, I'll de-reference the dependencies and then we'll have a brand new project dependency diagram that should be far cleaner to look at and more extensible.
Image


99 Compile Time Errors to knock down.
99 Compile Time Errors!
You take 1 down, refactor around
682 Errors to knock down.


User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Sun Dec 24, 2017 11:05 am

Massive amounts of work done in the last few days. HUGE update:

//Interfaces
I've created the interfaces for the entire program, and I'm in the process of remapping the references in the program to use the interfaces instead, which is most of the way there. Every class defines a relevent interface to connect derive from.

//Extensions
Added a test for BuildEnvironment, to see if I've built the program in Debug or Release mode without needing to use the #if and #endif which makes the code messy to read.

//SlaveObjectFactory and MasterObjectFactory
Created an object factory for creating all the interfaces. if I want a RichTextString, I create the object from the factory, then reference it and work with it via the interface. MasterObjectFactory references the entire program. SlaveObjectFactory references nothing. The entire program references SlaveObjectFactory. When I start the program, I link the MasterFactory to the SlaveFactory, so that when I call the creation from the Slave, it's actually occuring in the master. This way, no part of the program needs to reference any other part of the program, just the interfaces, and the SlaveObjectFactory to create the objects. Interface to work with, Factory to create. The complexity of the program just went from being a birds nest to a simple linear line.

//Color
Reworked color to use the interfaces. Needs to be redone a bit more as I finalised the interface for Color. Can convert from a SimpleColor (represented by a color code character like "A" for green or "0" for black) to a 32BitColor, with alpha, or anything inbetween.

//Logger
Works much like the Slave/Master object factory. I can call Console.AddMessage from anywhere, and the actual user interface links itself to the logger in the same way when the program starts. Ditto for Debug messages. I can call Console.AddMessage from anywhere in the program and it will show up in the Console UI window now. Previously impossible due to circular dependency. Ditto for Debug.

//ExceptionHandling
Basic Core for exception handling declared. Will be used to catch all sorts of errors in the program and write them to the debug window in future.

//UnitsOfMeasurement
Class redeclared in the interface, but needs to be implemented still, shouldn't take too long to do this now that the entire structure is declared in interfaces.

//Databases
Database is 90% of the way towards using interfaces ONLY and not relying on Colors, RichText etc. Few more things to change up here to get that all working (Read: Need to link everything to the ObjectFactory).

//IO
File, CommandFile, ListFile types all declared but need to implement the interface 100%. Almost there...

//Math
Changed up some of the coordinate systems to use generics. Now have Points, Vectors using IDistances, and Coordinate for generic types, and Orientation for angles.

Equations and statistics now using interfaces.

//Networking
Connection declared in interfaces needs to be reimplemented, not too much to change.
PacketProcessor declared in interfaces. Has a linking method at runtime much like Logger and ObjectFactory.
Packets have all been redeclared in the interface to use units of measurment where possible.Reimplemented up to packet 11(Flight Data) but more to go. Packet data is now easier to work with thanks to conversion from the packet data to a useable format in the program.
Server implements interface and can be created by the ObjectFactory.

//RichText
Now all using interfaces to be driven, no more inter-dependency. Created RichTextElement which describes one string, and it's particular color and formatting. A RichTextString is a list of Elements, and a RichTextMessage uses a string, plus a few interfaced Date and Time stamps plus a reference to the creating User.

//Settings
Now using interfaces instead of referencing the implementations.

//UserInterfaces
Improvements to the way messages are written in the console. Some message types now have the background colored differently. Can show and hide all message types according to the correct output window. Messages are drawn at an increased width if hiding date/time etc. Overall much prettier.

//YSFlight
Declared interfaces but need to implement them for DAT and LST files.

-----

So that's the full status of the program.

I'll give you another shot of the program dependency tree and code metrics. Hopefully there is an improvement. but I have 280 odd errors to clear at the current time, so maybe it won't even work...

Image

EDIT: Yep. Can't do the code metrics until I fix all the errors, Miught just have to stand by.

Do note that the complexity of that project dependency diagram is going to go way down over the next few days.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Tue Dec 26, 2017 7:16 am

Image

Geting flatter, still heaps to do!

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Wed Dec 27, 2017 5:32 am

Project Tree Organised.

Image

I've chosen the Interface -> Logger -> Exception Handler -> Slave Factory -> Extensions heirachy for the following reasons:
  1. Interfaces is the heart of the program, and has no implementations. Should not depend on anything as no computational functionality is here.
  2. Logger is able to write to the debug and the console. Every part of the program computation should be able to do this, so this is the next logical part of the hierarchy.
  3. Exception Handler should be able to be accessed from everywhere, but also needs to be able to spit out to the debug. So this goes after the logger, but no deeper.
  4. Slave Factory is the core for almost all object creation. There's bound to be issues here and there and I should be able to write and handle errors, to the exception handler.
  5. Extensions makes access to the slave factory objects much easier. This way I can do "SomeString".ToRichTextString(); rather than the much more convoluted ObjectFactory.CreateRichTextString("SomeString");. This should be top of the core hierarchy, with every other part of the program having all the information they need to work independently.
Okay, now time to wire it all up correctly!

I'm going to go the logical approach: Build from the base dependency to the top most dependency.

Will start with the interfaces, make sure they are all packed up nice and tight, then the logger, making sure that's finalised, so on... Then the Database, then the Permissions, then the YSFHQ connection...

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Thu Dec 28, 2017 8:50 am

Another day done. Progress suddenly exploded as I started to link everything up and clarify the interfaces.

Then I hit a minor snag:

See IFile defines List<string> Contents.

And ICommandFile derives from IFile, and also defines new List<ICommandFileLine> Contents.

The compiler is complaining about this.

I really don't want to change the name of List<ICommandFileLine> Contents, I want to encapsulate the base variable to make it safer to work with.

Going to have to think about this one. I think the issue is ICommandFile derives from IFile, so it wants to define List<string> contents in both the base class and the derived class but the derived class won't let it. Hm. It's a real head scratcher.

EDIT: Fixed it. I used an equals sign to define a field instead of defining a property with {get; set;}. Derp.

EDIT2: I have now done everything but the YSFlight loading modules and just 3 types of UnitsOfMeasurement. I've got DATFiles, LSTFiles, Metadata and World loading to take care of. Everything else is now done.

I should be finished with that part tomorrow, then I just need to link to the master factory where I will actually create each object I've definied in my slave interface. Home Stretch!

Currently 0007 though, time for bed.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Sat Dec 30, 2017 4:52 am

Quick update: Everything is implemented and tied together except the World loading now. 630 errors to work through there. That sounds daunting but I started at 1800+ this morning so...

I've still got to implement the creation of objects in the Master Factory though. Each one is just a one liner to reference the actual part of the program that does that.

With any luck, will have a working program again by the end of the day. Let's hope.

EDIT: Oh nice, turns out that 630 errors was because of a misplaced close bracket. It's actually 230. That helps. :lol:

EDIT2: The solution is successfully building again! Time to link the object factorys to the program.

User avatar
Flake
Staff
Staff
Posts: 4213
Joined: Thu Feb 10, 2011 8:47 pm
Favorite Aircraft: Honda CBR1000RR (2004).
Location: Australia
OS: Windows 10 (x64)
Has thanked: 790 times
Been thanked: 1101 times
Contact:

Re: Flakes Construction Yard

Post by Flake » Sat Dec 30, 2017 12:16 pm

Image

YEAAAAA BOIIIIIIIIIIIII

That was one of the longest, most arduous coding tasks I've ever undertaken.

But the good news is it's done and we've now got a strong platform to use for OYS for the future.

Just need to do some tidy up over the coming days, such as fix the way I'm using RichTextStrings to they render the way I want at all times when called within the code. Just little things now.

Oh I'll also have to go over the entire World and MetaData loading, make sure that's all good too.

You wouldn't believe it but we're stupid close to the old OYS capability now: I just need to define the remaining packets past packet 11 in the processor, then define commands handling, the database saving/loading, and maybe I'll code my OWN IRC client that is far less buggy then the one I used.

Image
Image

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest