Ørb# (Orb Sharp) Development Log

[Flake]

Commands are now threaded.

This is something I need to be careful with now, as multi editing the database can cause conflicts!

...I'll need to code "Locking" events to some functions to make sure only one thread has access at a time (ManualResetEvents).

The obvious benefit of course, is multistage commands. (/Someadvancedfunction... /ok.)

It's necessary for the advancement of development, so it's like swallowing a vile of poison to boost your immune system, in a way.

---

Coding primite database functions now. going with the approach "/GROUP.*.ADD etc. syntax. These commands won't be used frequently enough to warrant short names, and it keeps commands clean. For example. "/GROUP.YSRAAF.ADD NewUser AtRank" is better then "/GROUP YSRAAF ADDUSER NewUser AtRank" It is easier to distinguish command to parameters.

Back to work on that.

On another note, I'm much more frequently on teamspeak now, drop in and say hi! ys.ysfhq.com

[Flake]

Code: Select all

NetObj.ClientObject.SendMessage(Database.UserDB.List.Where(x => x.Groups.Select(y => y.Group) == ThisGroup).Select(z => z.Name).ToList().ToStringList());

And the award for most complex Lambda expression goes to....

(This function lists all members of a group...)

[Flake]

Advanced Messaging Optioned added.

Exclude/Include: Groups, Ranks, UserNames. (easy as List<NetObj>.Exclude(item))

[Flake]

Command Handler reworked a little in regards to arrangement of code, no major change though.

The command /Group.*.Add User is now working reasonably well.

Tested with the console, appears to work fine. Not tested with a YSF client yet, but they both use the same infrastructure so it should be okay.

Modified Server.ClientList and Server.AllClients. AllClients gets the console as well, for purposes of sending messages to it. where as clientlist only gets REAL clients (not simulated clients like the console).

Database is coming together well. Lambda expressions (and my brain!) are getting a workout though. it's really simplifying the code at least. Much easier to look at.

/Groups lists groups.
/Groups.GroupName does nothing yet... might have it show group info later (how many ranks, created, etc.)

it's worth nothing invalid groupnames/usernames are being caught and appropriate messages are being sent to clients.

---

Just did a code metrics count:

4590 lines of code at current, With Database making 2000 lines of which.

One good thing is my calculated code maintainability: most of it above 70%. some dirty modules dragging it back a bit (the ones in development).

All in 77% maintainability.

[Flake]

Groups Add and Remove user tested and working in full.

Enhanced console to have a command history, so you can scroll up and down rather then having to retype a bodged command all over again.

[Eric]

Everybody like this post. You'll find out why later. - OfficerFlake

(Eric has done some more awesome wizard shit. The best repayment I can give at current is upping his LEGIT thanks count.)

[Flake]

[Flake]

YSFHQ Mode is now implemented.

You can now use usernames over 15 characters (provided it is your YSFHQ username).

Hopefully all limitations will be overcome in the next YSF release.

[Flake]

Fixed some bugs with permissions loading/saving.

Fixed a bug that meant new users were not being connected correctly.

[Flake]

New IFF Rules:

IFF1: "Friendly" - Appear on own client as IFF1. Other Clients will see you on IFF1.
IFF2: "Appear As Enemy" - Appear on own client as IFF1. Other Clients will see you on IFF2.
IFF3: "Squad Only" - Appear on own client as IFF1. Other Clients will see you on IFF2, unless they are in your squad, then they see you on IFF1.
IFF4: "Enemy" - Appear on own client as IFF4. Other Clients will see you on IFF3. As IFF4 Is reserved for client only, when you join on IFF4, every other player aircraft will always be on a different IFF then you.

[Flake]

0b110100100 CODE IT FGT (inb4 nobody gets this joke)

[Flake]

Hi Dwayne,

Sorry. I was forgetting about it. Instead, I am changing log-on packet so that:

(1) If the username is 15-characters or shorter, same as before, and the packet length is 24 bytes.
(2) If the username is longer than 16-characters, up to 200-character name is included after the version number (20th-23rd bytes of the packet), and the packet length will be greater than 24 bytes. I thought about putting only 16th character and the rest, but I decided to repeat first 15 characters anyway. Saving 16 bytes for one-time packet is not worth, and might complicate the packet if I change it to UTF-8 encoding.

You should be able to intercept log-on packet and will know pretty-much the full user name, assuming nobody is going to use longer than 200-character username.

Does this solve your problem?

YES. YES IT DOES.

[Flake]

Can now promote/demote/rank users.

Promote doesn't allow you to specify lower ranks, Demote vice versa, and rank has no restriction.

If Rank is used without a target rank, you are instead told the current rank of user.

So so far you can add and remove users to and from groups, promote/demote users and users can choose which group to represent (eg: /Group.Orb.Represent == [ORB]OfficerFlake[ADMIN]: Hello, /Group.HAVA.Represent == [HAVA]OfficerFlake: Hello...) This should do away permanently with the need for "squad tags". As the server automattically adjusts your name for you, quick and easy.

I also adjusted username/rank/etc lookups to first search case sensitive, then case insensitive, then any username containing the word specified. If, in any search, only ONE match is found, it actions that user/rank/group etc...

Next commands will be add/remove groups from the console. Change group founders from the console (group founders have absolute power over a group), and then add and remove ranks to the group, and re-order ranks as needed.

[Deleted User 1872]

Thanks for posting up my video

[Flake]

[s]Ignore this, just testing something forum related, here seemed like an okay place...[/s]

HA. I just thanked my own post. Take THAT society.

[Flake]

Changed how sockets work for the last time.

YSFlight uses Blocking sockets. As the socket is closed by the ysflight client/host it sends a "close" signal.

This results in any receiving socket in orb to return "0" if it tries to get data from a closed socket.

I was umming and ahhing on the side of caution as I never fully understood this. I wasn't sure if it could return 0 if their was a delay in the data being sent. Because the sockets are "blocking" they "block" the thread when waiting for data, unless of course they have been told to close.

This means I can never get a "0" unless the socket has actually closed.

Socket disconnects are now being processed perfectly every time, and there will be no more changes to the socket receiving structure (less optimisation).

---

Groups can be added and removed on the fly now.

[Flake]

Fixed a bug with the YSFHQ Serverlist Bot, that was causing it to not update when connecting to Orb Servers (making them appear offline)

[Flake]

RichtextBox was crashing occasionally when writing to the feed. I believe this is a memory access violation when multiple threads are trying to edit the data at once.

I've coded a thread locking mechanism using a list. when writing to the feed, it checks if any other thread is waiting to write to the feed, and waits it's turn until it's first in the list.

It works sort of like the M1 Vulcan Canon in an F/A-18A. It relies on the first thread in the list working correctly to fire the next thread.

So, I coded a safety net for that as well!

The waiting threads all check the waiting thread list every second, if they time out. (unlikely). They then remove ALL intences of themselves from the waiting list, add themselves to the end of the list, and wait again. forever and ever, amen.

When a thread is done with writing, it removes itself from the waiting list, then checks the length of the waiting list. If the waiting list length is >= 1, it signals the first item in the list, letting it process.

Nifty huh?

For those of you that were on my server this morning, and then got disconnected, this is what happened: RichTextBox decided it hates you.

[Midnight Rambler]

No one knows what you're saying but it looks impressive.

Nice job

[Stingx]

No one knows what you're saying but it looks impressive.

Nice job

EXACTLY