Sadie: A clean code Habbo emulator
- Thread starter habtard
- Start date
TheGeneral
Active Member
- Dec 27, 2016
- 145
- 157
dominic
Active Member
- Dec 16, 2011
- 175
- 84
unless he's aware, it looks like he's using it as a singleton, so potentially being accessed by multiple threads are a possibility
- Thread starter
- #24
Its transient, contexts are short lived.
I've been away, but I'll pick this back up soon.
Minor Updates
- Removed redundant state variables (start time, version) relying on
You must be registered for see links
- Version now read from assembly info
- Cleaning up enums, sorting into folders
You must be registered for see images attach
Last edited:
- Thread starter
- #26
Player & room loading has been improved via lazy loading + other optimizations
Adding rolling (mp4;
You must be registered for see images attach
Post automatically merged:
Adding rolling (mp4;
You must be registered for see links
)
You must be registered for see images attach
You must be registered for see images attach
Last edited:
React
Active Member
- Sep 17, 2023
- 163
- 59
Will this be primarily used for Roleplay enviroment or Retro?
- Thread starter
- #28
Unsure yet, RP privately, I'll release for hotels at some point.
Can now go for a swim
You must be registered for see images attach
Code snippets
You must be registered for see images attach
You must be registered for see images attach
This is handled on the cycle updates of an individual room user, which means it can support any effect ID (as long as its mapped to a matching interaction type) and works in a generic way.
Other emulators had it implemented repeatedly across many interaction classes which I didn't like.
Last edited:
React
Active Member
- Sep 17, 2023
- 163
- 59
I would suggest as you said, keep RP environment private, until it's "ready". Even then, maybe release the roleplay part as a plugin rather than whole emulator, it'll save some people making minor edits to your work and renaming it, claiming as their own.
- Thread starter
- #30
Been refactoring today, tidying up some asynchronous bits. Applied some feedback from @TheGeneral
Working on docker stuff too so when I do release you can just compose the emulator, website and API from a single command.
Also extended test suite, Sadie now has 35 unit tests, up from 11.
More unit tests added
Just asserting tile map stuff
Lots of refactoring
Sadie now has the concept of room furniture item processor classes.
These can be registered by having any class that implements:
This means, you can have a plugin that just does this:
And it'll be picked up by the auto mapping:
Processors are ran periodically
This is what I meant when I said Sadie's plugin system will be extension driven not event driven (to start with at least).
Building on this but you can now implement your own processors, interactors and commands all through implementation and referencing Sadie.API
Working on docker stuff too so when I do release you can just compose the emulator, website and API from a single command.
Also extended test suite, Sadie now has 35 unit tests, up from 11.
You must be registered for see images attach
Post automatically merged:
Post automatically merged:
More unit tests added
Just asserting tile map stuff
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:
Lots of refactoring
Sadie now has the concept of room furniture item processor classes.
These can be registered by having any class that implements:
You must be registered for see images attach
This means, you can have a plugin that just does this:
You must be registered for see images attach
And it'll be picked up by the auto mapping:
You must be registered for see images attach
Processors are ran periodically
You must be registered for see images attach
This is what I meant when I said Sadie's plugin system will be extension driven not event driven (to start with at least).
Building on this but you can now implement your own processors, interactors and commands all through implementation and referencing Sadie.API
Last edited:
React
Active Member
- Sep 17, 2023
- 163
- 59
Could you let me know more about this intentions wise?
Last edited:
- Thread starter
- #32
I haven't meditated much on my intentions. I guess at some stage I'll release the Sadie.API project, which will be enough to customize it to whatever needs you require.
I'm trying to move the project more into an encapsulated core for emulation purposes state, then providing the API and ability to register additional / override existing services.
Last edited:
React
Active Member
- Sep 17, 2023
- 163
- 59
Sounds good, thanks for responding and again, good luck!
- Thread starter
- #34
Refactoring navigator stuff today
Filtering is now split into its own implementation class.
Example:
I would argue Sadie is the cleanest Habbo emulator written after the most recent batch of refactoring.
Also added unit tests for that stuff:
Filtering is now split into its own implementation class.
Example:
You must be registered for see images attach
I would argue Sadie is the cleanest Habbo emulator written after the most recent batch of refactoring.
Also added unit tests for that stuff:
You must be registered for see images attach
Attachments
Last edited:
React
Active Member
- Sep 17, 2023
- 163
- 59
I guess you'll have to put your argument into play when this is finished and compare with others
- Thread starter
- #36
More refactoring today,
Going to remove Sadie.Networking.Serialization from the solution at some point and make it a separate package.
After that, its about reducing dependencies on the inner game projects from outside scopes like events.
Get everything referencing API so it can all be decoupled at some stage.
Added support for mapping interactors to multiple interaction types:
This also means multiple iteractors can reference the same type (runs a collection).
Going to remove Sadie.Networking.Serialization from the solution at some point and make it a separate package.
After that, its about reducing dependencies on the inner game projects from outside scopes like events.
Get everything referencing API so it can all be decoupled at some stage.
Post automatically merged:
Added support for mapping interactors to multiple interaction types:
You must be registered for see images attach
This also means multiple iteractors can reference the same type (runs a collection).
Attachments
Last edited:
TheGeneral
Active Member
- Dec 27, 2016
- 145
- 157
Some more tips:
You can use [TestCase} attribute to pass a parameter / truth table to your test function. Values will get mapped to the parameters in the method.
Use [SetUp] to do shared setup in a [TestFixture]
You can use [TestCase} attribute to pass a parameter / truth table to your test function. Values will get mapped to the parameters in the method.
Use [SetUp] to do shared setup in a [TestFixture]
Post automatically merged:
Though order wouldnt be guaranteed at any point right? So whats the benefit over a single logic class?
- Thread starter
- #38
Thanks for this.
Refactored tests as suggested
You must be registered for see images attach
Post automatically merged:
Few updates
- Started working on wired, adding new tables, setting up architecture for implementations.
- Streamlined build process, we now build, test & lint on each push. If any of these fail, PRs cannot be merged.
Post automatically merged:
Cleaning up event handlers a bit, added support for custom attributes
Usage:
You must be registered for see images attach
Validated:
You must be registered for see images attach
Short hand for
You must be registered for see images attach
Last edited:
React
Active Member
- Sep 17, 2023
- 163
- 59
Still following, for the purpose of "fun" will you be implementing Wired 2.0?
If so, how do you plan to go about it? I haven't seen it on ANY English retro yet, though I am aware some of the foreign hotels have managed it.
A little bit of info regarding this would be nice, thanks in advance!
- Thread starter
- #40
Wired 2.0 will be tackled when the time is right.
On a more generic note...
Exciting news, we're moving towards open sourcing Sadie.
It all starts with our enumerations.
Nuget package:
You must be registered for see links
Git:
You must be registered for see links
As we reduce dependencies and projects become independent, we'll open source more of the code base. Once Sadie.API is published, you will be able to freely write extensive plugins and extend / override implementations with ease.
