Flakes Construction Yard

[Flake]

So today I improved the UI a lot more, so I'm not reusing code in places and it's less error prone.




Now console and debug inherit a common abstract console for their code base. Same with the debug/console message types menu.

Improved how richtextstrings are created so that the messages written to the console are less funky when being made and written.

All in all I'm happy with how the console and debug is working for now. Next I'm going to redo all the debug information in MetaData and World, because I'm very sure I've screwed something up there and I want to catch it before I progress any further into the netcode side of things.

[Flake]

I'm going to have to redo the UI to use WPF instead of WinForms, as everytime I try and write anything substantial to the form I get a AccessViolation exception due to memory errors in .Net's use of the forms. Fan-freaking-tastic.

EDIT: WPF is actually much easier then I thought it would be. I can design the UI in WPF, then do all the logic in traditional C#, then link it all up and voila. New goal for the next day or three.



This works pretty nicely. I like that I can see the output while working on the code, that's a massive help.

[Flake]

Gott Dammmmn this took ages to do!

WPF is both powerful and sometimes completely useless. After screwing around trying to set bindings, I decided the smartest way to do this would be to just do it all programatically.

I tried DataGrid, ListView, DataGridView, StackPanel...

In the end, it was just easier to use a Grid and then modify the Grid in code behind.

All working now. In fact, now I can have Debug and Console messages in the same window so what I'm going to do now is link those two together, clean up a bit, then stress test. Hopefully WPF is less cancer than WinForms and I can finally get on with it!

All this work for a UI! Christ all mighty! >:|

EDIT: Console and Debug are now one window. Will add checkboxes to choose to see debug messages which will all be off by default.



Unlike winforms, the loading for this is FAAAAAST.

[Flake]

Ayy friends, so I've been held up massively by WPF and it's complexities but I'm finally getting the hang of it.

Today I just created a simple sandbox to work on data binding, which is absolutely vital for how the settings will link in.

After much cursing at Microsoft, I worked out how to implement two-way data binding, and how to install Fody and PropertyChanged.Fody which will make UI linking so much cleaner and faster.

So now all I need to do is 3 things:
1. "Settings : INotifyPropertyChanged" and "public event PropertyChanged" on the settings class and Fody will take care of the rest of the UI update noticications, keeping the code clean and easy to read and work with. I don't want to have to mess with UI notifications when updating and changing settings, and this solves that issue.

2. I need to do two other things on the UI: "{Binding Path=<SettingName>, Mode=TwoWay" for each element of the UI, and "DataContext = Com.OfficerFlake.Settings" in the code behind, which will link the UI and Settings together.

3. Create the elements of the UI to control the settings: eg link a menu option to lock/unlock server.

WPF has been an absolute NIGHTMARE to learn, but now I've got the basics down, it's all I need to know as the rest can be sorted out in code behind!

Back to work over the next couple of days and weeks. Thanks for your patience as I learned WPF, it's been REALLY REALLY hard.

[Flake]

On the surface it looks like I've done sweet FA but what you can't see here is a great deal behind the scenes:

1) Settings class is slowly being converted to use INotifyPropertyChanged, and will evenetually be event driven to work with the UI completely. I'm just finishing all that up now.

2) The console output, though it looks no different, is now using a bound DataGrid. This is far less hacky then using a grid and updating with the code behind. Now, to update the UI with a new message, I just do: Messages.Add(...); A massive differernce.

3) I've managed to link up some of the settings already to the settings class. They don't do much but as a proof of concept it all works in both directions now. I can change a setting from the UI, and update the UI from a setting.

These 3 changes are a very big deal for the program now. I spoke with Kujo the other day and what needs to happen from here is:

1) Finish redesigning the settings.
2) Finish adding bits and pieces to the User Interface and link that to the settings.
3) Finish up the remaining packets.
4) Start with beta releases and testing, adding new features as I go.

Also: WPF is hard.

EDIT: Settings complete, but for converting some fields to properties. Quite organised and easy to use now. Logical.

I need tore-work how data comes into the console. I'm converting to objects as the messages come in, where I should instead reference the raw message, and use a converted to put it into textblock format. That should hopefully not take long but I'm ready to be made a fool of.

I'll be quite happy when I have the settings driving the UI fully and vice versa...

[Flake]

Hooray!

I can now show and hide any type of message from the settings, and I can load messages into the console on the fly.

Limited to 10,000 messages (works find, tiny bit of lag) and everytime it gets to 10,000 it will flush back down to 8,000.

Impact of the UI is negligable now. Very happy with this.

[Turbofan]

^Any chance clients can change their username without having to log off the server? Would be great for ATC sessions. Probably comes with its own coding headaches but thought it wouldn't hurt to ask .

[Flake]

It can be done yes.

I'd need to keep the username originally logged in as that is "hard coded" as soon as you log into the server. But I could definitely catch all chat messages and change the username, catch all join-requests and change the username, userlistings etc.

I'll try and set the server up to do that but getting a working server going first is priority 1.

[Flake]

Construction is moving on and I'm now linking the PacketInterface definitions to the PacketImplementations. That is, Packet_32_ChatMessage implements IPacket_32_ChatMessage, and so on, for all packets.

While doing this, I'm linking the MasterObjectFactory up to create these packet objects.

This might take a little bit of repetition but this is light work.

We're almost back to where we were, server side, before the massive program re-structure. I think I have about 12 packets or less to link back together before I can log into the server again.

[anthsco]

Very impressive coding work there.

[Flake]

So I can log in now, I have all the packets mapped out, but for some reason I'm not getting ground objects. (NANI!?)

More to come!

EDIT: Issue with lists loading. My YSFlight.World.Grounds.AllGrounds list is notdefined/null.

[Flake]

More progress:


Server will no longer load grounds it doesn't have. It will help you know why it didn't load them, so you can install them!


Debug messags for world loading is complete. This will help me in the long run should I need to see what's going on. I might add some more detail to future releases if I need it.


Ground objects are now being loaded from FLD and YFS. I'm still having an issue with HAWAII where some ground objects aren't spawning in the right location. Might be an issue with my code for moving child scenries down to the root scenery, which I hope to have sorted out soon.

EDIT: Pretty sure the error is in how I assumed child sceneries were stored in the FLD file, and how I can load them.

I thought that each PCK would define only one child scenery, and reference others by referencing FIL. It turns out, that the PCK can also have other PCK's embedded inside it, and this was tripping up my loading of child sceneries, as when I reached the 2nd PCK, the first PCK would be finalised when it shouldn't have been. I'll need to code a new way of loading sceneries now.

[Flake]

That ought to do it.

The top image consist of a VOR in the root scenery, a Tree2 sitting on top of the VOR, inside a child scenery (Root/1.fld), where that child scenery is rotate 90 degrees. Finally, the other tree, Tree1, sitting just on the north apex, is a child of the child scenery (Root/1.fld/2.fld, and again moves the tree about. This multi-level test of concept has proven the reliable loading of OpenYS to display ground objects on servers, no matter how complex the child tree is.

Hey in fact, the good news is that the new structure for loading FLDs is very easy to read and maintain, so this could prove a strong base to load polygons, pictures, motion paths, areas in future. I intend to use this functionality.

Thanks to Decaff for sending his VORFinder program... But honestly your program ain't gun work son

What if the VOR is in a Child Scenery, and needs to be rotated and moved about? What if it's in multiple sub-child sceneries?

Your program does move by child-scenery, but assumes the scenery would never be rotated.

Time to add some more packet handling I guess.

[decaff_42]

Good point. That is a hole in the code but it seems to work pretty well for the few test cases that I ran. I think you are more likely to have the airport scenery be rotated slightly, rather than a large portion of the map like an island.

For your purposes, not nearly accurate enough!

[Flake]

Messages are being sent successfully now.

Refactored world loading so it's all clean and ready to use now.

Going to try and get join requests acknowledged and leave notifications acknowledged today as well.

[Flake]

Changed the way things work a little and now my ground objects are in the wrong place haha. I'll be able to fix that pretty quickly though. EDIT: done, back to normal.

In other news, handling the first join requests now. Working pretty well, a few little caveats to catch and take care of here and there.

Debug is proving quite effective.



Fixed the grounds and I can now spawn on the ground as well. I'm facing the wrong direction because I'm not inverting the X axis for heading when loading orientations from STP files I do believe. I can fix that pretty quickly too I hope

I am very close to releasing first Alpha. I just have to handle and process the leave-flight notifications, and then make sure flight data is sent to all connected and logged in clients.

Hopefully I can do that tomorrow. Be warned though. The new server will barely do anything. It'll be a test of concept - can you log in? Join flight? Leave flight? Send text messages? Does the UI Crash? This sort of work is what will be tested in Alpha. While that's happening, I'll review debug logs and fix errors as people report them to me.

Current Sprint:

• Finish Join Request Handling.
• Implement Leave Notification Handling
• Implement Send Flight Data
• <ALPHA RELEASE>

[Nodoka Hanamura]

I leave for a year (iirc) and I find out OYS is getting a nice revamp and we've learned some things about the netcode (I knew (obviously) that YSF netcode used some kind of keep-alive system over TCP/IP, but this is nice. Keep up the good work, Flake.

[Flake]

Yep, in fact the netcode sorta looks like this:

1. Login - Username, Version
2. ???
3. Error
4. Field - Name, X, Y, Z, H, P, B
5. Add Entity - Type, Username, Identify etc.
6. Acknowledgement - Various opcode numbers
7. SmokeColor - VehicleID, GeneratorNumber, R, G, B,
8. JoinRequest - Identify, Fuel %, Start Position etc.
9. JoinApproved - <Nothing>
10. JoinDenied - <Nothing>
11. Flight Data - Position, Speed, Strength, Time, Ammo, G Loading, Guns Firing etc.
12. LeaveNotication - VehicleID
13. Remove Entity - VehicleID
14. ???
15. ???
16. PrepareSimulation - <Nothing, sent when login complete>
17. Heartbeat - <Nothing>
18. LockOn - X locks onto Y
19. Remove Ground - ID, <Deletes a ground from the server.>
20. Ordinance Spawn - AAM, B500, Flare etc.
21. Ground Data - Like flight data but for ground objects.
22. Damage - X is damaged Y amount with weapon Z.
23. ???
24. ???
25. ???
26. ???
27. ???
28. ???
29. NetcodeVersion - Send by server when logging in.
30. AircraftCommand - VehicleID, Command, Parameters - Much like DAT File commands. This is how I make aircraft invincible - I set their strength to a ridiculously high number ever server tick.
31. MissilesOption - Enabled or Disabled.
32. ChatMessage - RawMessage, eg: "(Username)Hello" or "**** ENDURANCE MODE START ****"
33. Weather - Blank is requesting the weather, otherwise: Lighting, Options [Land Everywhere, Blackout, Collisions, Fog], Visibility, Wind X, Wind Y, Wind Z. <I'd manipulate this packet on old ORB to have that funky disco lightning effect in the old YSF versions>
34. ???
35. ReviveAllGrounds - <Nothing> Simple packet, tells the client to set all grounds health back to 100%. This is what the ReviveGrounds button on the stock server does.
36. WeaponsLoadout - ID, Multiple Enties of [Weapon, Quantity]. Eg: ID, GUN 3000, AAM 2, AGM 2....
37. ListUser - ID, Username, UserType [Client/Server Flying/Not Flying]
38. QueryAirstate - Not sure how to use this fully yet but pretty sure: B;ank = request or list of ID's that are still flying.
39. WeaponsOption - Enable or Disable unguided weapons and guns.
40. ???
41. Username Distance - Always, Never or Distance in Meters.
42. ???
43. Server Command - eg: "NOEXAIRVIEW TRUE" to disable the F3 View or "RADARALTI 200M" for a radar height of 200m or higher above ground.
44. Aircraft List - Version, NumAircraftInThisList, List of Identifys. Eg: "Version 3", "2", "BLOCKPLANE", "B747"
45. Ground Command - Aircraft command, but for a ground object.
46. ???
47. Force Join - New netcode only, if not in flight, forces client to send a join request. Could be useful for doing parachute stuff but never really worked due to poor implementation.
48. Fog Color - R G B
49. Sky Color - R G B
50. Ground Color - R G B. <I would manipulate these packets every server tick to create the sunset/sunrise effect on old OYS.
51. UNUSED
52. UNUSED
53. UNUSED
54. UNUSED
55. UNUSED
56. UNUSED
57. UNUSED
58. UNUSED
59. UNUSED
60. UNUSED
61. UNUSED
62. UNUSED
63. UNUSED
64. USER PACKET - SubType, Data, so the fullpacket would be [Size, Type=64. Subtype, Data], then you could do whatever you want. Eg: Subtype=11 for custom flightdata packet. Vanilla YSF ignores this packet, but OpenYS accepts it and works with it so long as it knows how the subtype packet works.

[Flake]

Spawning in the correct direction for both entity joined and flight data. Also spawning with the correct velocity in the correct direction, so aircraft aren't doing any backflips like in the old OpenYS tests.

Also implemented join/leave flight notifications.

I was facing the wrong way on the runway because the initial flight data packet had an error - I was setting the wrong bits of the heading, in the wrong fashion (Single should be Int16).

We can now chat, join flight, leave flight on servers. Now to send that flight data to everyone else (quick job).

Then I'll see about releasing the first alpha test. The map will be Hawaii only and the server will run on port 7915 only. Again, this is only temporary until I get the settings loading from a settings file implemented.

For now, I need to sort out having join notifications get sent to other clients...

EDIT:

Okay one of two things need to happen:

1) I work out some more tricks regarding the entity joined packet, so that the NON-owner client doesn't send a flight data packet reply, if that's even possible.

2) I implement the vehicle management class which tracks where vehicles are on the server and who owns them, so I can ignore flight data from clients that don't own the vehicle.

I might need to do some proxy server sniffing with the vanilla YSF Client, which means coding up a packet sniffer and proxying tool, which will be good long run but will slow things down by about a week or 3.

[Flake]

So I really need to understand packets better.

Because of this I'm making an inspector tool to make my life a lot faster in the long run. The idea is I can then use this tool with a proxy server to see what the vanilla YSFlight Server does - that way I can learn from and emulate it.



I've made the UI for the tool so far, but I've hit a small snag today.

OYS is currently written so that the program starts, it then creates a new thread for the user interface and then starts an application for the main window to run on in that new thread.

I cannot have more than one application running per thread - something I didn't know was not allowed until today.

The solution is now to create a new thread to run a WPF application in, but then the WPF application thread will need to be able to accept input from the main program, telling it to make a new window, or close one etc.

It's not TOO much work to change the way that works but I won't get anywhere at all without it.

So to summarise, I do currently make a UI thread, but that UI thread and window creation are tied - the UI thread doesn't listen for any input from the main program. I need to change that, so that I can make more windows.

And that's the goal for the next few days: Make a new "application" interface - that is, a code-behind that can accept commands and input from the main program.

EDIT: YAY I DID IT!



So, the way forwards was to:

Create a Singleton Instance for handling the application side of the UI, then re-write and clean up the current userinterfaces to create their window through that singleton object. The clients still use their own dispatcher, which really just refers back to the UI thread.

To be clear: You can only have one WPF Application per AppDomain (Program). My previous method was trying to make new applications everytime I needed a window. I instead needed to make one Application and then make that application be able to create windows when I tell it to.

Next step will be to code a proxy mode into the connection, confirm that's working, and then link the inspector.