Re: Revolution Server (Java, PRODUCTION)
Again @Wotsuba, good luck for the project. Waiting new screenshots of progress. Latest progress i saw was you entering at HotelView..
Generally new emulators tak 1 week to already "Enter in HotelView working", but seems you're stuck in this.
If you need help, i'm here...
Re: Revolution Server (Java, PRODUCTION)
@Wotsuba
I see you use annotations for linking fields in your classes to your databases, what framework do you use for this?
Also why do you have to manually say its nullable or not? This can also be defined in the database. So if you change it in the database you also have to modify the emulator.
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
The General
I see you use annotations for linking fields in your classes to your databases, what framework do you use for this?
JPA 2.0
https://github.com/HeyItsKawaii/Revo...ersistence.xml
Quote:
Originally Posted by
The General
Also why do you have to manually say its nullable or not? This can also be defined in the database. So if you change it in the database you also have to modify the emulator.
And It's just so the Hibernate DAO won't be able to set the value as null, it can still be a null value it just can't be "nulled". Default is true so I only set it false to values that I know won't be null when I'm building DB tables.
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
Wotsuba
JPA 2.0
https://github.com/HeyItsKawaii/Revo...ersistence.xml
And It's just so the Hibernate DAO won't be able to set the value as null, it can still be a null value it just can't be "nulled". Default is true so I only set it false to values that I know won't be null when I'm building DB tables.
Yeah but like if you make changes in the database to allow null, you have to modify your source code again.
Re: Revolution Server (Java, PRODUCTION)
Goodluck with project and enjoy the fun Gamelogic development.
Re: Revolution Server (Java, PRODUCTION)
Err... Whoop! Guess it's that time again...
Changelog (7/17/2016):
- Now using Hazelcast for IMDB instead of Redis
- Hibernate now uses Hazelcast for 2nd level caching
- Room Manager functional (in-development) uses ConcurrentHashMap for caching of RoomBean objects which contain the "Room" JPA Model which stores all of the room data obviously.
- Room Manager uses object synchronization for room loading and unloading and other room fonctionnel that utilize the "put" and "remove" map functions.
- Room Manager switched from Synchronized THashMap to ConcurrentHashMap
- RoomAvatar which is now the Player's and Bot's Room instance has been started on, prepareRoom() , enterRoom() has been written but not yet tested because I no longer have my server
- Removed PlayerService, now using PlayerDao which is no longer an extension of the GenericJpaDao
- Renamed all of the Events and Composers classes removing the "Message" from them because consistency matters, only packet values will contain "Message" in the name.
- Configured libraries not to log weird shit to the console, log4j2 now logs errors and information in separate files under the /logs directory
- Hazelcast now being used to cache Navigator search queries (mediocre implementation will be revised in the future)
- Cleaned up the JPA Models annotations, redundant variables removed from the annotation.
Like I've said before, room entering has been written it just hasn't been tested yet because my server was turned off, but I'm going to set up a localhost in a few...
- Room Models and Heightmap have yet to be coded
- MemorySession (previously RedisSession) has yet to be coded
- Habbo Encryption has yet to be refactored
GitHub: https://github.com/HeyItsKawaii/Revolution
Re: Revolution Server (Java, PRODUCTION)
Rewrote the Habbo Encryption in JavaScript/Node.js using Hazelcast to communicate with the server.
I know I might be overengineering a tad but Node has a solid RSA & DiffieHellman implementation in C++ and I will be utilizing JavaScript/Node for other things such as PathFinding in the near future.
I haven't progressed any, I might release a version using Pre-Shuffle first before Post, because of the lack of "features" required.
???
Screenshot by Lightshot
Judge for yourself
https://github.com/nodejs/node/blob/...node_crypto.cc
Lemme know whatcha think!
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
Wotsuba
Rewrote the Habbo Encryption in JavaScript/Node.js using Hazelcast to communicate with the server.
I know I might be overengineering a tad but Node has a solid RSA & DiffieHellman implementation in C++ and I will be utilizing JavaScript/Node for other things such as PathFinding in the near future.
I haven't progressed any, I might release a version using Pre-Shuffle first before Post, because of the lack of "features" required.
???
Screenshot by Lightshot
Judge for yourself
https://github.com/nodejs/node/blob/...node_crypto.cc
Lemme know whatcha think!
I don't understand why you are incorporating NodeJS into the equation at all.
There isn't any point going overboard for the sake of it when you already have the ideal libraries and resources native to your project.
You'll end up creating more overhead which ultimately equals to a less desirable solution.
But hey, that's just my opinion.
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
Francis Joseph
I don't understand why you are incorporating NodeJS into the equation at all.
There isn't any point going overboard for the sake of it when you already have the ideal libraries and resources native to your project.
You'll end up creating more overhead which ultimately equals to a less desirable solution.
But hey, that's just my opinion.
The current Habbo Encryption in Java wasn't as accurate and speedy as the latest one in C++/Node.js. One reason being... it's Java. Not here to start WW3 but we all know what's faster, and the fact that Java's littleEndian uses signed bytes, we don't get as close to the metal as we need to (metaphorically speaking) we're limited to things such as byte size.
It also crashed sometimes. XD
As I've explained before, I chose Node over Java for multiple reasons... select libraries being oine of them. I can see your point though, although what I'm using Node for (multiple features) I don't expect to hog much resources rather than have a ++ performance impact on the overall server.
Certain languages have their strengths, and this way my scripting/plugin system would be much easier (familiar) to work with.
Scalability is also a factor I'm considering, especially when it comes to the usual performance (memory leaks, etc) Habbo Emulator problems being PathFinder and Habbo Encryption. I mostlikely won't have to worry about either.
The current Java implementation will be kept in the source but not maintained by me until further notice, whether you choose to use it or not is your decision.
I'd hate to spoil the surprise but my pal @Joopie helped out a lot, unknowingly.
Re: Revolution Server (Java, PRODUCTION)
Then steal my pathfinder. Define not fast enough? Mine could handle 250 bots in one room with no problem. You are never going to need more than that really.
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
The General
Then steal my pathfinder. Define not fast enough? Mine could handle 250 bots in one room with no problem. You are never going to need more than that really.
If you want me to, then I will. But since I already have an implementation in Node, I'll keep both. Everybody loves options!
:marchmellow:
Saves me a lot of time,
Cheers.
Re: Revolution Server (Java, PRODUCTION)
No that was sarcasm. You better dont copy or steal.
I am just pointing out that your statement is bullshit.
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
The General
No that was sarcasm. You better dont copy or steal.
I am just pointing out that your statement is bullshit.
... I don't get it? :sleep: Have you not read my sig?
But anyways, no worries I won't use your PathFinder... I can code my own.
JavaScript Library:
https://qiao.github.io/PathFinding.js/visual/
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
Wotsuba
The current PathFinder in Java wasn't as accurate and speedy as the latest one in C++/Node.js. One reason being... it's Java. Not here to start WW3 but we all know what's faster, and the fact that Java's littleEndian uses signed bytes, we don't get as close to the metal as we need to (metaphorically speaking) we're limited to things such as byte size.
It also crashed sometimes. XD
As I've explained before, I chose Node over Java for multiple reasons... select libraries being oine of them. I can see your point though, although what I'm using Node for (multiple features) I don't expect to hog much resources rather than have a ++ performance impact on the overall server.
Certain languages have their strengths, and this way my scripting/plugin system would be much easier (familiar) to work with.
Scalability is also a factor I'm considering, especially when it comes to the usual performance (memory leaks, etc) Habbo Emulator problems being PathFinder and Habbo Encryption. I mostlikely won't have to worry about either.
The current Java implementation will be kept in the source but not maintained by me until further notice, whether you choose to use it or not is your decision.
I'd hate to spoil the surprise but my pal @
Joopie helped out a lot, unknowingly.
Whatever floats your boat, scalability is a factor as you said.
Which also means to consider the hardware in-which will be running your software and so forth.
Be sure to endeavor into unit testing and benchmarking too, since it would be project specific.
Doing your research is one thing but testing and analyzing it for yourself is another.
Re: Revolution Server (Java, PRODUCTION)
Quote:
Originally Posted by
Francis Joseph
Whatever floats your boat, scalability is a factor as you said.
Which also means to consider the hardware in-which will be running your software and so forth.
Be sure to endeavor into unit testing and benchmarking too, since it would be project specific.
Doing your research is one thing but testing and analyzing it for yourself is another.
Wasn't going to start unit testing until room walking was done.