Server Discussion SharpStar - Proxy server with support for C#, Python, Javascript, and Lua plugins

I should probably look up the naming conventions myself. Each language has it's own sort of culture with it's on standard... but also each company you work for, each professor you write assignments for, ect. It's a messy world out there. I'll dig through Sharpstar a bit and try to match up my own convention with that. Sharrybound has had a few authors I think, so no surprise that things end up messy in such an informal environment as hobby projects. We get what we pay for after all!

 

Version 0.2.6

• Bug Fixes
• Lag should *hopefully* be less of an issue now. If you experience any though, please let me know.

Note: I have not yet updated the .NET 4.5 version.

 

I have already said in this thread that I was running Aegis Gaming's server, kind of sad you didn't make that connection to the Aegis Wrapper.

What made you change your mind about java?

Edit: (On the subject of full rewrite) As most of you probably know, someone is/was working on a rewrite of the server from scratch.

 

I know your vaporware. Shall we pull up old post regarding your promises and lack of. Whats funny is you said a java wrapper....like you never heard of one yet you wanted PEX style permissions. Which is a java plugin for a java server managment tool. I also have not changed my mind. Was working and distracted. Probably worded it wrong.


We all know about the server re-wright. At least those who hang in dev channel.

 

I know what PEX is, having used it extensively for over a year, but the idea of PEX is not limited to java. It is just a node based permissions system which is fully modular. The permissions system in StarryPy requires you to edit base permissions as well as every single individual plugin. Instead of having each plugin defer permissions to a single location.

The trouble that got Aegis Wrapper and (probably) ROFLCopter's server development stuck is the handshake packet encryption, if you want good server software decode it and post it or figure it out yourself. The Aegis Wrapper was running on our server from pretty much launch up until Enraged Koala, and it had no performance issues, even with the large amount of players we had daily.

 

So what are the benefits of this wrapper compared to starrybound, aside from the plugin system?

Does it perform well for instance? Is it relatively bug free? (i.e. no major bugs that prevent people from joining/playing at all).

Can I use it on linux? (could not find info about this in the main post, I guess it's somewhere in the thread)

EDIT: nevermind that last question, was just below the main post

Another question though, does it automatically start the starbound server too if I start the wrapper?

 

From what I can tell, the core of what makes up SharpStar is,
- Decodes game packets and creates mirrors of various game structures (players, entities, projectiles, ect) for reference
- Provides an optional account system (users can login using account/password fields)... as UUID (character IDs) are easily copied, this is a big deal
- Provides extensive plugin support giving plugins access to that information

I'll stress that the plugin system is a major advantage. The plugins can be very powerful, allowing you to add practically any feature that can be supported with what we know of Starbound's packet structure. Sadly there is still a lot we don't know about those packet structures, but we know enough to do quite a few useful things. The account system is the other big advantage. The other wrappers tend to use character IDs (UUID) to authenticate. At this point, if you do that, you're handing over the keys to the kingdom to any griefer that wants to look for it. With a simple client mod, you can capture UUIDs of any player that exists on your current world.

As far as performance, I ran an initial test on a server with 20-30 players logging in at the time... it did not perform well. There is, however, a recent fix that should address that. I hope to run another test tonight, but we'll see how that goes.

The wrapper does not automatically start starbound. That would be rather platform specific, so it stands to reason SharpStar wouldn't support it so early in production. You could do that with a plugin though.... basically start the starbound process when the plugin loads. Start a timer. Check for the process each time the timed function runs and restart starbound if the starbound process isn't found.

 

Thank you for your helpful answers, that's all I needed to know!

 

Hope the test runs well, but I would say that it is easier to setup a restart script which will take less resources/keep the server software slim (if you are having a lot of traffic on your server).

 

A restart or managment of the .exe for sb really ... resource wise would not take anything extra enough to make a difference.

 

I tested the 0.26 version wrapper with my chat bypass plugin. There were 30-40 players on at the time. No trouble! There didn't seem to be any more movement/monster/ect lag than normal. It was a fairly short test... only about 15 minutes live, so hardly conclusive, but things do look good now.

I won't be around this weekend to test more, but I'll get back on things when I return.

 

Great news! . Keep me updated on your tests.

 

Why would you want to add any unnecessary load to the wrapper even if it is small?

Was your chat plugin separate from the Access Control plugin?

 

Version 0.2.7:

- Clients now have an Id assigned to them
- General Bug Fixes
- Misc changes

New Plugin (Item Blacklist Plugin):
- Allows you to block certain items (will kick player if blacklisted item is detected).

Note: At this current time, it will only detect items in the ship locker. This is because player data is not transferred to the server, so this is a WIP until Chuckleflush decides to transfer player data from client to server.

 

How is the client ID assigned/different than UUID?

 

The client id is just used to track online players internally; every time a player joins it assigns an id to the connecting client. This is more reliable than tracking online players by name/uuid.

 

Being an int, the client ID is much quicker for compares than the UUID, which is a string. This matters for performance in code that will run a lot.

The client ID will be a major boon for plugins that want to store their own data on each player, as they have to do those compares quite often. I've been using object compares to match player data, which is better than string compares, but not ideal, since I have to check to make sure object references are valid first. I'll be switching over to client IDs right away. It will be slightly faster with less potential for error.

Hell yes! This will be a bigger help than you might have expected.

 

Great! Glad I could help.


Version 0.2.8:
- Fixed warp methods in StarboundClient
- Assign Entity Ids to the players
- A few minor bug fixes

New Plugin (Essential Commands Plugin):
Commands:

• /makeadmin
• /removeadmin
• /kick
• /ban
• /broadcast
• /giveitem
• /addperm
• /removeperm
• /setmotd
• /warpto
• /warptome
• /kill

 

Version 0.2.8.2:
- New way for C# plugins to register commands/events. (example below)
- Events are now also triggered for packets that are sent from SharpStar (including plugins).

Example:

Code:

public class MyAwesomePlugin : CSPlugin
{

    public override string Name
    {
        get { return "My Awesome Plugin"; }
    }

    public override void OnLoad()
    {

        MyAwesomePluginCommands commands = new MyAwesomePluginCommands();

        RegisterCommandObject(commands);
        RegisterEventObject(commands);

    }

    public override void OnUnload()
    {
        //code here
    }

}

public class MyAwesomePluginCommands
{

    [Command("command")]
    public void MyCommand(SharpStarClient client, string[] args)
    {
        //code here
    }

    [Command("commandtwo")]
    public void MySecondCommand(SharpStarClient client, string[] args)
    {
        //more code here
    }

    [Event("someEvent")]
    public void HandleSomeEvent(IPacket packet, StarboundClient client)
    {
        //code to handle event here
    }

}

By registering commands/events this way, it is now a lot easier to split them up into as many different classes as needed.

Essential Commands Plugin Update:
Added more commands:

• /addadvert
• /removeadvert
• /toggleadvert
• /ship
• /who
• /worldwho

 

ArchGaden, have you been able to perform more tests with the wrapper?

Also, Mitch do you have all these commands listed with syntax somewhere? (on a wiki?)