So I've decided to use this thread basically as a blog to let everyone know what's going on in my own little project using Rose Malaysia evo source with a heavily modified osrose server that is basically a hybrid of rev 81 (droprev) (just prior to DR2 and my own KTRose pre-evo source, all compiled in Visual Studio 2010 because it's just better than codeblocks
This project has been ongoing but pretty slowly for a couple of years but has been going in full swing since about last November.
The first stuff i did, WAAAAAY back was to remove all trace of packet encryption because it's really completely pointless and it was causing all kinds of problems.
Next I decided to take a leaf out of Pre-Evo and make the client load files from regular directories in preference to loading from VFS.
I was a little TOO successful in this. Somewhere along the line I broke VFS loading for a specific yet undetermined file type in VFS so right now I need to run my client with the entire VFS extracted. TBH I can't be bothered to go back and figure out which file type won't load from VFS at this stage so I'm putting it off as long as possible
First thing I did after this was to make the decision that the client will no longer be allowed to make any calculations about move speed, HP, MP or really stats of any sort so i started digging.
So far I have managed to take most of them out of the client completely. HP, MP, Attack Power, Defense and best of all, MOVE SPEED are all completely controlled in the server. I even added a set of 'Cheat Mode' variables in the server to act as over-rides when the stats are calculated.
So right now a GM character can use the command '/setstat movespeed [speed]' to make his move speed just about anything. Same goes for AP. I haven't specifically coded any others as GM commands yet.
To get all this to work properly I had to actually add a few completely new packet structures to both the client and server as well as making some changes to a few existing ones such as adding HP, MP, MAXHP and MAXMP to the 0x07ec packet.
the result of all this is that...
I no longer have jumping HP and MP
I can move at any speed without crashing the server (via hack controls) when I run through a map portal
Decided to mess with item drop rate (Number of drops in an individual drop event) and item Drop Count (number of stackable items in a specific drop. Kinda like Stockpile skill that actually works)
Then I decided to get jiggy with it
I never liked the way that Items had those weird stats that went away when a Gem was applied so i started thinking of ways to make items truly unique. The result was the introduction of the UStat system
See the purple stat 50 Attack Power?
there can actually be two of these and they are 100% unique to the item in which they are set. there is no lookup table. It doesn't take data from an STB or anything. We just have a UStat[0 and 1] and a UValue[0 and 1] value where the stat can be any number and the value can be any number. This allows for stupid stats like Headsize 300 (although that doesn't actually work right now. I'm working on it though) or more useful things such as Summon_Gauge 20 (allowing for more summoned pets)
Any item that drops has a chance of a random UStat or 2 and any items from chests will always get them. I still need to write a function to make them make a lot more sense though but that's minor compared to making them work in the first place.
I had to redesign the CItem class structure in both client and server AND the entire inventory packet system had to be overhauled to do away with that horrible GetItemHead() function with it's nasty bitshifts and stuff. Same for GetItemBody(). Both of those functions appeared in about 6 million different and confusing places throughout the code. Now any time we need to send item information we just use "AddItemData" and it builds the entire item and adds it to the packet in a nice centralized location so that the next time I need to add something to the CItem class I can do it once in one place. Much neater.
Then i thought to myself, "why let the STB control the size and level of monsters?"
It always seems stupid to me that we have 20 different Candle ghosts in the STB. Each one just scaled up a little from the previous one? Why not just have one basic model? set it to level one and let the server scale it up to suit?
So i modified monster spawns (only GM command ones so far) so that the packet to create the monster in the map sets it's size and level via the 0x0792 packet
This is what happened when I tested it but got some code wrong.