It's useful I guess, but one thing I'm wondering:
Did you made the name Marshaller yourself? My dictionary doesn't contain that word...
It's useful I guess, but one thing I'm wondering:
Did you made the name Marshaller yourself? My dictionary doesn't contain that word...
I need some feedback from you guys!
I currently got 1 way of implementing the new Auto Event Message generation structure:
What needs to be done is ->
Create easy-to-implement interface classes with easy structures to add into your existing emulator code
After that calls will look as follows:
With IHabboContext beeing a class which has some information in it regarding getting the needed data.Code:ServerMessage message = new ServerMessage(); Marshall.FillResponse(message, Outgoing.SomeCodeHere, IHabboContext);
ALL data needed for the Event is than stored in the message object which can be send directly to the client.
This will require some time to implement in all servers, but I will take into account the default "code structure" from most of the servers.
The packet creation GUI itself will be posted tomorrow or Monday and the implementation could should e straight forward.
The GUI itself will be able to:
- Create structures with dynamic for-each operations - Needed for friendlist, items in a room etc
- Create if statements - Needed for Club packets, groups anything that requires it
- Send all kinds of basic data (uint, int, string ushort, short, byte etc)
Is there anything else that needs to be taken care of- packet wise?
IMPORTANT>>>
I will not use C# Attributes to map values from habbo's rooms etc, as they tend to be slow at runtime. I've made a choice to use Interfaces instead as they tend to be a whole lot faster
Normally, marshalling means the process between managed and unmanaged code, so the CLR has to make sure the memory is usable by unmanaged code, it can do so by pinning memory or copy memory. However, this is not the case for the marshaller project. We named it marshaller since it takes care of the process by finding the correct event ID for the current SWF revision you have selected.
- Martin
Would this give users the ability to 'update' - should it implement your ID marshaller?
Nope. Its the same reason as Jordan said on the first page. There is enough stuff to put my hands on in the server :)
- Martin
Project update:
Spoiler:
I've finished different major parts of the event message creation.
What still needs to be done for a new release is:
- Add all object in the object bench.
- Add enumeration support
- Add save to web interface
- Create documentation on how to implement this in your server
All calls will be routed through 1 new object which you will need to implement.
It's very straight forward. I will give more details when im finished with enumeration support.
Regards,
Dissi
Bfly already has such a system in place (event id loading, not message structure). I'm making it compatible with your servers as well.
The project itself will be used to help the community with the complex structure of the packets.
Especially now the client stops working if it received 1 malforming packet.
I would like to help the community to overcome this obstacle with an easy-to-implement packet builder.
Which happens to be fast to use, and easy to update. I don't see the harm of that.
Either way, we could also just "borrow" packet structures from the released sources. It's not that hard
Actual updates:
Image 1:
- Added support for loops
- Better look for the packet data
- Implemented up/down buttons
- Implemented delete button (forgot about that)
Spoiler:
Image 2:
- Added casting support -> Also support Boolean to Integer fields
- Added loop filter -> the only type which is accessible as data from the loop is in the object bench, no other objects can be selected
Spoiler:
General:
- Added loading/saving for casting of types
- Made preparations to load actual construction of the EventData creator for the server
- Added some interfaces to show you guys this progress
Last edited by Dissi; 16-01-13 at 09:29 PM.