Flakes Construction Yard

[Flake]

Great success today:



That's me inspecting from the 8th byte on a chat message packet.

If I looked at the raw data, I might not have known that was a string, but the inspector clearly shows what the data type is.

Next step will be to implement a "proxy mode" packet handler, which will just send client packets to the vanilla YSF server, and vice versa. Then I can inspect inbetween.

EDIT: Proxy mode implemented and I am now inspecting data from the vanilla server.

EDIT2: The inspector has already proven it's worth. For entity joined packet:
0-2 UInt16 ENTITYTYPE [00 Aircraft, 01 Ground]
4-8 UInt16 VERSION [Should always be 01]
108-112 UInt32 OWNERTYPE [03 Player, 02 Other]
112-116 Single HTRADIUS
116-118 UInt16 ISHELICOPTER [00 NotHelicopter, 01 IsHelicopter]
118-120 UInt16 CATEGORY INDEX [00 Normal, 01 Utility, and so on, in order on the aircraft select screen]
120-124 ??? UNUSED [UInt32???]
124-140 String USERNAME [16 chars
140-172 ??? UNUSED. [32 chars]

Looking back over my preivous assumptive code, I would have been saying: All entity joins are owned by the player, all had a radius of 10m, no aircraft were ever helicopters. All aircraft were aerobatic category.

I'm guessing entity join requests were failing because their data was 140 instead of 172. I'll try that and see what happens. I went back over the start of the packet and I would set the join version incorrectly each time an aircraft would join the server - the version was set to 0, which would surely screw everything up. I'll define the new packet structure and try again from here.

[Flake]

First multiplayer online flight.

It's just a proof of concept for now, I have each client assigned a vehicle ID.

I'd much rather assign each client a Vehicle instead, that way I can look at the clients vehicle to see where they are in the world.

So from here I'll need to add a Vehicle class much like OYS 1 had.

When that's done, I'll need to handle leaving flight gracefully, and then I can work on handling things like damage and ordinance spawning, then finally with the vehicle class and EntityJoined packets fully mapped out now, I can add vehicles to new clients that connect. I'll also add in the "query airstate" - which pretty much tells a client "these aircraft ID's are still flying, so pay attention to these flight data packets".

We're not far off a functional vanilla server.

[Flake]

Vehicles class is implemented. I actually had to do just a little bit of a work around, because most things were aircraft centric and they should not have been.



In this screenshot:

The first client joined the server.
The first client started flying.
The second client joined the server.
The second client can see the other aircraft.

I hope this will always work but this should solve a long standing bug of OYS 1 where sometimes you'd join and not see the other aircraft on the server.

EDIT:

Ordinance spawns are now being passed to all other clients.
Damages are now being passed to other clients.
'Fixed a bug where the color gold was actually green. (lol)
Stacktraces are now easier to read, should make bug reporting easy as now you can just copy paste from the program or take a screenshot, and I'll be able to solve promptly.

I still need to clean up the world loading, and then implement settings loading. Once that's done I'll release first alpha.

After that, I'll implement weapons loadouts and weather, then clean up the project and release beta.

Then it'll be periodic updates as I add each new feature. It's almost ready!

[Flake]

A lot of behind-the-scenes work has gone in over the last few days.

I cleaned up the entire project tree now things are pretty well finalised, so it's a lot easier to look at and a lot cleaner too.

Here's the project tree structure and an overview of what it is to look at in the solution explorer:




So a few changes:

1) I'm signing the assemblies now using a strong name key pair. Anyone who wants to use this source will be required to do the same.
2) Developers of this source on github can fork, then make their key (.snk) and also make a copy of DeveloperInfo.cs and edit that - in that file, they will put their username and their builds will be signed with their name, not mine.
3) Icon changes from my OfficerFlake logo to the OpenYS logo
4) Cleaned up Metadata and World loading a great deal - it's now loading from the directory specified in settings.
5) Codified the entire project structure. Much easier to see references and how the components interact together.

This is a massive change behind the scenes from the mess that was the code before I did the clean up - It doesn't look like much but now the code is lot easier to look at and work with.

EDIT: Now able to load from Settings.Dat - I stress again, able to load, not actually loading from.

I'm testing the loading of specific setting data-types right now. Eg: DateTime, Distance etc. What I've tested so far is working. I'll keep working to hopefully ensure the ongoing stability of this.

[decaff_42]

I can't imagine the amount of work you have done re-writing this and optimizing it. No doubt your work will help online flying and the ysflight community as a whole.

Keep up the amazing work!

[Flake]

More work.

PacketInspector is now hidden on launch, and can be revealed by clicking the magnifying glass icon.
Which means I am starting to implement the UI icons. I intend to link up the UI to the Settings more robustly.
Speaking of settings, I am now able to both load and save them. Before I was only loading.

I'm working on cleaning up the UI backend a little bit, so I can work on creating an OpenYS Client. Some people have been asking for a distance lag solution for some time and the program base is at a point where I can start doing that.

I'll need to have Proxy Mode track vehicles, then I will need to add vehicles and despawn vehicles when the proxy server receives this information. After that, I'll need to have the proxy send an OpenYS Server Handshake, which tells the vanilla/OYS server that the proxy connects to that it supports the custom user packets. I'll then add a formation position packet. If it all goes to plan, that should be all that is needed:

1) Vehicles for ProxyMode
2) OpenYS Handshake
3) Formation Data Packet Handling

It's actually closer than I thought! I just need to think over how I will do the formation position packet...