Sadie Emulator

[habtard]

You must be registered for see images attach

Discord (live updates):

You must be registered for see links

Introduction
Sadie is a clean code emulation server targeting the latest PRODUCTION release of Habbo. It's written in C# / .NET core with Windows and Linux support in mind. The repository has received over 500 commits and development is still ongoing.

Project Goals
To provide a clean, stable emulator base for future reference, for myself or anyone who wants one.

Why another development?
Its been in active development for 2 years so its not fleeting. I started it before I quit habbo. The release of the Nitro client motivated me to finish it. Even though I don't play anymore, I wanted to finish it.

What's finished?
All core functionality is pretty much there. You can login, create rooms, talk, browse catalog, buy furniture, place and move the furniture, assign rights, send friend requests, set relationships, actions, dance, signs, respect, and more. It would be easier to describe what's not done.

Why post now?
Its reaching a point in its development where it can be tested and showcased.

See below for a few screenshots.

Spoiler: Screenshots

You must be registered for see images attach

You must be registered for see images attach

You must be registered for see images attach

Post automatically merged: Mar 27, 2024

Few more updates since yesterday

You must be registered for see images attach

Can't upload screen casts here as their too big so check discord for those.

Post automatically merged: Mar 28, 2024

Back with another daily update.

Lots of refactoring, improvements to room tile state management, bug fixes and more.
See commits below;

You must be registered for see images attach

Automatic Testing
On each push to develop, a docker container will now also be span up to run the unit tests which will enforce standards going forward

You must be registered for see images attach

Post automatically merged: Mar 29, 2024

Refactored all of the event handlers that read data today (50+ classes took a while), data reading now done via a singleton parser class for each event.

You must be registered for see images attach

Post automatically merged: Mar 30, 2024

Highlights

Merged 150ish commits to main from 0.7
Anything below is now 0.8 tag

• Fixed a few bugs reported via our testers.
• Did a ton of refactoring.
• Fixed some bugs with player subscription expirations
• Players can now purchase club memberships
• Added catalog page serializer for HC layout

You must be registered for see images attach

You must be registered for see images attach

Did a bit of work on stacking items, still needs some work though, I also want to refactor how room tile state for quicker mutation

You must be registered for see images attach

See discord #updates for live commit updates.

 

[TheGeneral]

Good luck! More people starting .NET emulators recently, great to see!

What are you using for your database? Simple mysql connection or an ORM?

Couple personal suggestions:
Split your parsers and DTOs. Then you can abstract away your networking part and more easily run simulations / tests.
You might want to consider code generation for your DTO. Saves you a lot of time writing ReadInt, ReadString.
Consider using an auto DI scanning library so you dont need to manually add each new services.

 

[habtard]

Good luck! More people starting .NET emulators recently, great to see!

What are you using for your database? Simple mysql connection or an ORM?

Couple personal suggestions:
Split your parsers and DTOs. Then you can abstract away your networking part and more easily run simulations / tests.
You might want to consider code generation for your DTO. Saves you a lot of time writing ReadInt, ReadString.
Consider using an auto DI scanning library so you dont need to manually add each new services.

Thanks! ADO.NET which I've tried to abstract down with a base class etc (see

You must be registered for see links

&

You must be registered for see links

), its very verbose, something like

You must be registered for see links

or maybe even entity framework could really help with not writing so much code for that.

Yep, adding parsers was one step to reducing the coupling so eventually I can seperate the responsibilities like you describe.

Also yeah, using something like reflection to recursively register the events would be much easier as its an ever growing complexity otherwise, will look into this soon.

It's good to see people being constructive.

Post automatically merged: Mar 31, 2024

Few more updates

Did some work on club offers, now loading them from the database.

You must be registered for see images attach

You must be registered for see images attach

You must be registered for see images attach

Added

You must be registered for see links

(adds extension methods to M.E.DI) for easier service registration:

You must be registered for see images attach

Post automatically merged: Mar 31, 2024

Refactored events so each one declares its packet identifier via a property (auto mapping).

You must be registered for see images attach

Post automatically merged: Apr 1, 2024

Bit off topic... I wanted to improve code quality and enforce certain rules for Sadie but couldn't find anything better than a basic linter.

I spent some time last night writing a really rough C# analyzer, it uses the Roslyn .NET compiler and provides abstractions for things like class and individual method line count, parameter counts, etc

It runs off a config file like so:

You must be registered for see images attach

zsh alias for pre-commit

You must be registered for see images attach

It returns the suggestions count as its exit code (!= 0 will fail) for things like

You must be registered for see links

You must be registered for see images attach

Back on topic...

Commands now define their own trigger keyword via an attribute, instead of defining a collection map.

You must be registered for see images attach

Other highlights

• Done a ton of refactoring with suggestions from the code-quality-checker.
• Started moving catalog packet writers to shared serializers so the code stays DRY
• Spent some time playing with Entity Framework, will (probably?) switch Sadie to it soon.

Post automatically merged: Apr 2, 2024

Spent the day working through some refactoring, room paint settings, and catalog front page items.

Packets now pass front page items, loads from db, etc:

You must be registered for see images attach

You must be registered for see images attach

Room painting done, wall and floor thickness, as well as paint for floor, wall and landscape (see discord for screen cast, can't upload), plus a few other trello items.

Post automatically merged: Apr 3, 2024

Busy upgrading a few things with my set up today but a few commits:

You must be registered for see images attach

Post automatically merged: Apr 4, 2024

Working on lots of paint related stuff, fixing a few bugs, added a few catalogue page serializers.

Starting implementing Entity Framework, which cleared up a lot of boilerplate for the ADO stuff. It still exists, but its on its way out.

Even though EF is a repository pattern I'm keeping the repository classes for testing / mock ability and separation concerns.

Lengthy DAO classes are now gone and repository classes are now cleaner as a result

You must be registered for see images attach

You must be registered for see images attach

Will move all the other stuff over to use it in the next few days and drop ADO.NET for good.

Post automatically merged: Apr 5, 2024

More updates today

Moved all of furniture, catalogue (items, pages, front page items, etc), and navigator to Entity Framework. All that's left now is player and rooms old data access layer then ADO.NET is gone.

This is taking some time to write up all the models and configure the relationships, and I don't want to get distracted so its all I'm focusing on right now. New features will come but the transition to EF core was a must for Sadie which is getting there...

You must be registered for see images attach

Players and rooms are huge in terms of tech debt. They hold more data access related code than all other projects combined, but I'll be tackling those in the coming days.

Post automatically merged: Apr 7, 2024

April 7th, 2024

• The EF transition is fully complete for room project
• Separated persistent and BL entities using auto mapper
• Done a ton of refactoring in response to the EF upgrade
• Started migrating players project to EF (about 10%)

Plan for the next few weeks will be finishing EF transition, more refactoring and stabilisation work, then maybe an open beta.

Post automatically merged: Apr 8, 2024

April 8th

• EF transition is complete solution wide

Post automatically merged: Apr 9, 2024

April 9th

• Dropped tuples project wide for .NET 8's
  You must be registered for see links
• New permission system (roles now many to many, player can be many roles).
• Improved enumeration parsing with description attributes
• Lots more refactoring and clean up work

Post automatically merged: Apr 10, 2024

April 10th

• Refactored entire solution
• Got migrations generating via EF
• Can now lay down on lay able furniture.
• Fixed a bug where status doesn't update coming off chair
• Started working on furniture interactions (clicking)

You must be registered for see images attach

You must be registered for see images attach

 

[habtard]

April 11 & 12th

• Brought in new contributors
• Lots of refactoring
• Multi tile furniture now works well
• Wrote some new unit tests

You must be registered for see images attach

Post automatically merged: Apr 13, 2024

April 13th

• Moved all game constants to the database
• Added a development mode to ignore SSO security
• Can now set welcome messages for players
• More unit tests & refactoring
• Brought in more developers

Post automatically merged: Apr 14, 2024

April 14th

• Rewrote walking algorithm
• Decoupled SSO tokens to its own table
• Added a CONTRIBUTING.md
• Made a wiki for code styles (
  You must be registered for see links
  )

In the next week or two, I'm planning on open sourcing Sadie.
I've been working on a few projects to make it more usable when released.

Includes;

• A dedicated CMS written in Svelte Kit
• A REST API written in GO
• A schema converter script written in PHP

You must be registered for see images attach

 

[Liam]

Good luck with this.

 

[habtard]

April 15 & 16th

• Added option validators for configuration (@Damien)
• Switched fleck for dotnetty
• Lots of work on the CMS & API
• Some work on the schema converter too.

Schema converter is a lot of work, some data is difficult to copy because of the differences in structure, I've managed to convert everything I've tried so far except permissions, because of their different names and weird structure.

Sadie works many to many, players can have many roles, a role can have many permissions etc. I'll look closer at this when its time to release. Check out our discord for more up to date changes as I'm probably forgetting some stuff here.

 

[dominic]

why not use EFCore?
why use DotNetty when .net core offers a perfectly good TCP socket framework internally? (makes you able to support both WS and TCP with the same handlers)

also remember Nitro is iffy, so you can't build it around Nitro and expect it to work with Air (for example)

 

[habtard]

why not use EFCore?
why use DotNetty when .net core offers a perfectly good TCP socket framework internally? (makes you able to support both WS and TCP with the same handlers)

also remember Nitro is iffy, so you can't build it around Nitro and expect it to work with Air (for example)

1. We've transitioned to EF.
2. Its a nice way to achieve non-blocking, asynchronous I/O, provides a larger abstraction than

You must be registered for see links

if that's what you meant? .NETTY is even easier to align your pipelines so WS connections get upgraded and treated like TCP.

Nitro is iffy? I'd like to hear more...

 

[LeChris]

1. We've transitioned to EF.
2. Why use .NETTY? Its a nice way to achieve non-blocking, asynchronous I/O, provides a larger abstraction than

You must be registered for see links

if that's what you meant? .NETTY is even easier to align your pipelines so WS connections get upgraded and treated like TCP.

Nitro is iffy? I'd like to hear more...

Nitro doesn't implement everything correctly but it's not really a big deal since it's most of the way there.

Why is Air even brought up? Nitro is mobile compatible and is better than a downloaded app, just seems like a silly thing to chase Sulake for an inferior experience

 

[Damien]

I think he's refering to the Flash client in general.

While Nitro is amazing, you're right in saying it's not completely accurate, and since it's goal is to mimic the flash client as close as possible, we too should be targeting the flash client first.

By doing this we can better identify what Nitro is doing wrong and help Nitro get closer to replicating the flash client. After all this is a Habbo emulator, it's purpose is to emulate as much of Habbos server as possible, and if a new client comes out with a more accurate packet handler than Nitro at least we don't have to refactor the emulator because we've coded it around Nitros short comings.

 

[dominic]

I think he's refering to the Flash client in general.

While Nitro is amazing, you're right in saying it's not completely accurate, and since it's goal is to mimic the flash client as close as possible, we too should be targeting the flash client first.

By doing this we can better identify what Nitro is doing wrong and help Nitro get closer to replicating the flash client. After all this is a Habbo emulator, it's purpose is to emulate as much of Habbos server as possible, and if a new client comes out with a more accurate packet handler than Nitro at least we don't have to refactor the emulator because we've coded it around Nitros short comings.

Yeah, the flash client definitely serves as a good base, for testing.
Nitro was built around Arc/MS which did do a lot eh to make it work :-D.

Yeah - DotNetty doesn't cut it for me, because you have to "make your own" http protocol initially, which .net web already does for you and then expands on that protocol with the WebSocket class - pretty easy tbf.

EDIT1:
(I think Netty itself did introduce a HttpHandler - unsure whether or not DotNetty introduced this as well)

EDIT2:
Well technically speaking, Air can still be used as a client for players to use (no its not in-browser or on mobile) but it does the job - aaaaaand you can pretty much recompile it out-of-the-box.

 

[habtard]

Yeah, the flash client definitely serves as a good base, for testing.
Nitro was built around Arc/MS which did do a lot eh to make it work :-D.

Yeah - DotNetty doesn't cut it for me, because you have to "make your own" http protocol initially, which .net web already does for you and then expands on that protocol with the WebSocket class - pretty easy tbf.

EDIT1:
(I think Netty itself did introduce a HttpHandler - unsure whether or not DotNetty introduced this as well)

EDIT2:
Well technically speaking, Air can still be used as a client for players to use (no its not in-browser or on mobile) but it does the job - aaaaaand you can pretty much recompile it out-of-the-box.

Unsure how you've used it, but its goal is to be 1:1 with netty.

It's had HTTP codecs for a few years now and provides a far greater level of abstraction. Until you mention specific cases where .NET would be better I don't see a reason to re-invent the wheel.

Nitro does have some quirks I've noticed but nothings perfect, we've opened GB issues for the ones we care about. We have no desire to support the air client right now.

April 19th (this morning)

• Fixed a bunch of issues with walking, avoiding redundant recalcs
• Added exception handler for task worker, separate thread.
• Added cancellation tokens to a few things on shutdown / dispose

Getting ready to merge into main for 0.8 tag, also been focusing on the CMS & API so rate of progress has declined temporarily while we finalize the 0.9 board & get any open prs merged.

 

[dominic]

Unsure how you've used it, but its goal is to be 1:1 with netty.

It's had HTTP codecs for a few years now and provides a far greater level of abstraction. Until you mention specific cases where .NET would be better I don't see a reason to re-invent the wheel.

Nitro does have some quirks I've noticed but nothings perfect, we've opened GB issues for the ones we care about. We have no desire to support the air client right now.

April 19th (this morning)

• Fixed a bunch of issues with walking, avoiding redundant recalcs
• Added exception handler for task worker, separate thread.
• Added cancellation tokens to a few things on shutdown / dispose

Getting ready to merge into main for 0.8 tag, also been focusing on the CMS & API so rate of progress has declined temporarily while we finalize the 0.9 board & get any open prs merged.

DotNetty is literally re-inventing the wheel nowadays, since WS is natively supported by MS.

(what is GB?)

Nitro doesn't just have quirks, I think @TheGeneral mentioned that the way it processes incoming packets are incorrect, hence why you cannot just switch been Nitro and Air without hassle.

I strongly advice you to look into Air, before building it around Nitro ending up with a bunch of incomplete stubs.

Would love to see some code examples, looks like you're doing great.

 

[habtard]

DotNetty is literally re-inventing the wheel nowadays, since WS is natively supported by MS.

(what is GB?)

Nitro doesn't just have quirks, I think @TheGeneral mentioned that the way it processes incoming packets are incorrect, hence why you cannot just switch been Nitro and Air without hassle.

I strongly advice you to look into Air, before building it around Nitro ending up with a bunch of incomplete stubs.

Would love to see some code examples, looks like you're doing great.

I can't comment on the state of Nitro because I haven't studied the client enough, I just recall having to do some weird stuff on outgoing data for Nitro to understand it the same way flash was fine with it but this was over a year ago.

I have no desire to ever support Air, I think Nitro is great, why not work collaboratively towards improving it?

Also I meant GH, GitHub whoops...

You must be registered for see links

Finally I wont spend time re-iterating over points I've already made. Dotnetty offers a very nice level of encapsulation that we're happy with for our specific use case. It brought our networking code down from 100's of lines to sub 100, and simplifies the task of adding additional communication layers to our application.

Updates
Closed a few PR's this morning, will merge dev into main this afternoon (250+ commits) for the 0.8 release. Will also release a planned work items list (0.9 board) when ready.

CMS (svelte) and API (go) is complete and live at

You must be registered for see links

, but I'll announce details on these in a separate thread and/or on the discord when I'm ready.

 

[dominic]

I can't comment on the state of Nitro because I haven't studied the client enough, I just recall having to do some weird stuff on outgoing data for Nitro to understand it the same way flash was fine with it but this was over a year ago.

I have no desire to ever support Air, I think Nitro is great, why not work collaboratively towards improving it?

Also I meant GH, GitHub whoops...

You must be registered for see links

Finally I wont spend time re-iterating over points I've already made. Dotnetty offers a very nice level of encapsulation that we're happy with for our specific use case. It brought our networking code down from 100's of lines to sub 100, and simplifies the task of adding additional communication layers to our application.

Updates
Closed a few PR's this morning, will merge dev into main this afternoon (250+ commits) for the 0.8 release. Will also release a planned work items list (0.9 board) when ready.

CMS (svelte) and API (go) is complete and live at

You must be registered for see links

, but I'll announce details on these in a separate thread and/or on the discord when I'm ready.

\> api in go
\> ws in dotnetty

\> doesnt like reinventing the wheel

well i wish you the best of luck not reinventing the wheel a third time. can't wait to see your progress though.

 

[habtard]

\> api in go
\> ws in dotnetty

\> doesnt like reinventing the wheel

well i wish you the best of luck not reinventing the wheel a third time. can't wait to see your progress though.

You seem stupid, hence why I'm not investing much time into replying to you.

There aren't any web based projects that support Sadie, this would be the initial one hence the creation so people have something to work with.

Writing a web socket server with HttpListener isn't re-inventing the wheel but writing one in a popular security and unit tested networking library that encapsulates 90% of the logic is?

 

[TheGeneral]

Nitro doesn't just have quirks, I think @TheGeneral mentioned that the way it processes incoming packets are incorrect, hence why you cannot just switch been Nitro and Air without hassle.

I strongly advice you to look into Air, before building it around Nitro ending up with a bunch of incomplete stubs.

Nitro has been build against shitty Arcturus as ground truth instead of the official Habbo servers. Mistakes in Arcturus result in issues in Nitro.

 

[habtard]

April 20th

• Finished player periodic currency reward system

You can now define periodic rewards of any type using the database.

You must be registered for see images attach

Code Snippet

You must be registered for see images attach

You must be registered for see images attach

Any rewards given are also logged in the periodic_currency_reward_logs table.

You can also toggle between two settings with this option in server_settings

You must be registered for see images attach

Enabled (Fair): Rewards will go off a players online time
Disabled (Unfair): Rewards fire on a fixed interval regardless of player online time.

Few other bits

• Avatar data (motto and figure code) now saved live on change for instant website updates
• Fixed an issue with dbContext in multi threaded scenarios,

Catch us at the

You must be registered for see links

!

Post automatically merged: Sunday at 6:42 AM

April 21st

• Tons of refactoring, rewrote all of tile mapping
• Added a few new unit tests ( related to tile mapping )
• Refactored commands to list their required permissions

Commands
We've added a few basic commands (14 to be exact). Our plan with this is based on

You must be registered for see links

. Further customization / ability can be done via plugins.

You must be registered for see images attach

Few code snippets

You must be registered for see images attach

You must be registered for see images attach

Post automatically merged: Monday at 2:20 AM

April 22nd

• Refactored commands with further utility methods and options
• Working on user walking collisions and over lapping
• Added a server error writer for when the client sends an unknown header
• Refactored room creation and loading

See here

You must be registered for see images attach

You must be registered for see images attach

Post automatically merged: Tuesday at 4:38 AM

April 23rd

• Added placement validation to furniture placements
• Worked a lot on tile mapping and updating status re-actively
• Optimized EF usage to be more optimal on record updates
• Players now load their rooms on login to avoid re trips to the DB

You must be registered for see images attach

Post automatically merged: 2 minutes ago

April 24th
- Working on

You must be registered for see links

You must be registered for see images attach

April 25th

• Added accounts settings page to SadieCMS
• Added staff page to SadieCMS
• Added player profiles (/profile/[username]) to SadieCMS

April 26th

• Working on the schema converter, about 80%
• Packet writers are now serialized from their properties

You must be registered for see images attach