I'm here for my annual v26 chat visit.
I'm out see yeah next year!
I'm here for my annual v26 chat visit.
I'm out see yeah next year!
I think the people who were around for v26 would love to see it come back, the issue is that none of those people have the time to build a stable server to be able to bring it back. This includes myself, in the past month I have had as little as 8 hours to actually do any coding on my server, the rest of the time I have been working, socialising and generally trying to live a life. I begun working on Habbo when I was about 12-14 I'm now 19, I just have too much going on in my life to put the work into a server like I used to.
Hopefully I will be changing job near the start of next year, once I have a full drivers licence and a car, I will then be able to get a job closer to home (I know it sounds weird, I cycle to the train station and take a train into London at the moment as I can't find work locally as I can't get any transport there)
Once I have changed job (hopefully to a job that's only 35 hours a week instead of 40) I should have a reduced travel time too (it's currently 4 hours of travel a day - if I work 35 hours a week and 2 hours of travel a day I've saved 15 hours a week) which can go back into programming.
I hope some other people are trying to do some stuff too, I have reached a point where I need at least 4 solid hours to get anywhere as I am going through every packet and de-holographising it, I redid the entire console and made it fully functional including bringing back categories. The way I've done it also means I can give bots an instance of messenger and have some sort of AI running to talk to them.
There's a lot we can do with v26 to make it exceed the old days, the trouble is the time we have to do this. It almost requires a community effort but still to this day I am unsure of who I could trust to help me build such a project without it turning into holograph again...
I did look at your development thread, it looks like you've made good progress, my only qualm is that I don't like Java. I find it to be quite unmanageable at times. However it is not a bad language and hopefully a lot of people will use it and we will see some activity again from the old Shockwave community.
I know you said don't post about an r63, but what about R54 (same protocol)? I think the old, old flash client was really good, then it turned into caca. It saddens me nobody makes old Flash hotels at all. They had all the basics of v13, including pets. Then Habbo got weird. This was all before wired and such, I believe, since Wired came in r62 IIRC. However, if a new and from scratch v26 server was made, I would totally hop in just for the nostalgia, same with any v13.
You're right, my bad, I can't believe I forgot that. Hebbo was the first to have it, I guess that was their beta testing of it. On another note if you e.g. take a well known and usable server like Butterfly (I recommend the one Jonty released from Zap r63a) and you "downgrade it" (get rid of things that weren't in r26 and fix the login (I think it's just a different header) you could have a r26 server that ran with 1,600 people online or more without much noticeable lag. Takes a bit of work though, but it's doable, and a cheap trick. :)
That's quite a good idea actually, I still don't think it's the best idea for r26 overall. The problem I see with it is that a lot of emulators are not built properly. Albeit I have never seen the Butterfly version that Jonty released so I can't comment too much, but a previous version of Butterfly I've seen didn't impress me that much.
Still a clever idea, never thought of it that way.
The one he released might not look pretty, I maintained it for a few months, and I barely had to do much to it since it had been maintained by other people before me, however, it still held up many users. If it works, it works,I just highly recommend if someone knows what they're doing, for the love of sane development fix some of the things wrong with the database for Butterfly, I will gladly provide suggestions for what should be highly considered, I never did them myself because I didn't want to deal with migrating all that data, it's just not my area, never bothered trying to migrate and I wasn't about to break an entire hotel over it. Though now that I think of it, maybe I should investigate migration software.
Well I should start having more time at home, albeit I won't work on Butterfly 'cause I already have an on-going development but I will look into the version I have and see if there is anything I could use, especially when it comes to packet handling. My current issue is I have reached so far into redoing the packets by separating them into separate classes based on their actions, i.e. MessengerPackets, but I have hit a wall... I'm not entirely sure how I can let these be invoked without creating a new instance of each class per user, at the moment that would be about 15 classes per user not including the other classes they need... I am considering moving all the packet classes into being abstract and having the User extend them all, that would solve the issue but cause other issues.
When I come up with a nice solution I will be another (large) step closer to completing my server. I will at that point fork my project as personal and release.
Since I was originally developing this server as an RP emulator, that will stay for my personal version, I will re-include all the packets I removed such as events and build all their relevant systems again. I hope within a month or two I can have a public release with a completely new database. I haven't even started on a CMS though, which is rather annoying, I am unsure as to how long it will take me to rip the PHPRetro theme and remake the entire CMS again... Might be a much later release.
You could create seperate classes for each packet. Then for the composers have them interface (eg: composer) some kind of method like send and then have a method that takes any arguement interfacing composer.
This is how I wrote a system and I'm able to call the gameclient() and then use .sendResponse(new SomethingComposer());
Working on a stable system that is easy to use in many ways and easily adaptable takes time but will pay off in the end.
Building a CMS from scratch takes about two weeks. I've done multiple CMS' myself and they are usually nearly finished after two weeks. Building the core usually takes me 3 to 4 days. After that its just building each page and creating their database structure.
Your concept is great for sending packets but not receiving. There's a lot of data management within a received packet, it's not quite as simple as calling a pre-built static class, after-all packets technically are part of the User and not a general thing to be used elsewhere. I will take a look most likely next weekend into how I could do it and report back on what I've come up with. I just disagree with throwing hundreds of functions into the User class if it is only going to be called by the socket, the packets should have reference to the user but not be thrown into their class as if it's some sort of shared storage unit.
I had considered shortly after my previous comment of having a layered system, where I have a packetHandler which extends each packetClass, this would mean they were separated into separate classes but are called through the top-level packetHandler, this would mean the User only has one instance constructed rather than 20+. Thoughts?