Incase anyone is interested, i started work on the site about an hour ago can be found here
Printable View
Incase anyone is interested, i started work on the site about an hour ago can be found here
Unrealistic goals I think.
http://reaverpt.eu/version/images/exp.png
You could do that, but it would corrupt every character on your server if you did anything other than "add" levels. Changing the experience of lower levels "on the fly" would just break every existing player.
It could be done if you force logged everyone out, modified the exp of players to match the new table before allowing them back in... but you may as well take the server off-line to do that.
--- EDIT ---
Things you could store in the server SQL would include player data, warehouse data, shop inventory, NPC locations and data, monster spawns, monster details, PostBox data, logs. Additionally, if you implement "extra packets" you could distribute item lists, maps, ageing failure rates, mixtures and other crafting recipes to the client. But those would take some considerable re-working of both client and server.
Maintaining compatibility with official clients is a "popular" thing, so if you do that, that should be your first "fork". :thumbup1: (ie. main fork does not "improve" the original feature set... it may work better, take less memory, be easier to configure and so on, but will not add or remove features, the second fork will be fixing fundamental flaws in the original design)
http://reaverpt.eu/version/images/skills.png
That's stored in the client, not the server... I'm not sure what you imagine achieving with that.This is asking to be shut-down.Quote:
a share in all revenue generated from Support Donations.
Any emulator must be distributed purely in source form, for no profit and purely for educational purposes.
I believe individuals can donate / offer reward for bug fixes, but these must effectively be a private transaction which does not pass "through" the project, which must be a non-profit organisation. Advertising or sponsorship, even charitable donation is acceptable, provided it only ever goes towards running costs, and never individuals or labour cost. (as far as I'm aware)
Again, that's dubious. Leave that to RaGEZONE members to make "repacks" is my recommendation. (have you noticed that MaNGOS, SD2 etc will never offer binaries, even though you can find them all over the web? There is a reason for that. :wink:)Quote:
Binary versions of the project setup will also be available
skill damage is not stored client side, delays are, but i never mentioned that. These will be stored in a database, as will item values, the pre existing dat files will be stored in a database. The website isnt the final cut, as i said i started it an hour before posting the link. I filled it out with crap text so that it wasnt a bare shell. I never said anywhere that the emu would be distributed as a binary. I mentioned i would add other useful source code's that users could modify or if they wished could be distributed as an executable, which i have no worry of being shut down over as all those things would do is modify dat files and download information from the net, or update database values, in which case there is no solid connection to anything breaking any kind of rule or law.
I plan to use the SVN to be the sole distribution method for the project. I dont understand the issue with support donations however, ragezone takes donations to keep the servers running and no one has an issue with that... i probably wont even end up taking donations as i never have with my servers previously and probably wont start now.
If smart database programming is used you can update on the fly experience, you do not need to disconnect anyone, only force the client to update its variable values of what it has stored, if an increment is made in experience gain needed or a drop then the server can have a built in sub to handle such an event. Thereby re-sending the correct values to the client and keeping everything running smoothly(provided you have a client with an adabptable xp table) obviously at present we do not have such a client but i believe forward thinking never hurts.
Hold tight and i will get the site into a more release worthy state, the main reason i am posting it here is that i am enthusiastic about starting the project and i wanted to get some design input of what users who might want to be involved would like to see, basically because i cannot speak for everyones taste. The content on the site at the moment is irrelevant, i am trying to get a partially filled shell so i can visualise how the project will look upon completion.
Edit--------
Removed the issues you had from the site.
Yea... the "design input" is kinda what I'm offering. Only, design of "words". New wording is much better.
People are constantly trying to shut RaGEZONE down, and MentaL works hard to keep it up. The service(s) provided by RaGEZONE are not those of a server, or a development project. That's part of why he has to be very careful what the RaGEZONE name is put to. Essentially it's an MMO developers "speak easy". So if you shut RZ down, the development would continue, but communications would have to move to eMail, IRC or MSN or such.
pServers which take donations are "dubious" in legality, if those donations can be shown to go to individuals. (ie. as profit or earnings) They must only be used to fund hosting, and accounts must be able to prove that. However, you can make "personal donations" outside the organisation. (to a friend, for any or no particular reason) Very complex, I know. The fact is, friends don't ask for donations on a website. :wink: You can offer "rewards" for anything you like to strangers, and because you are asking for a service, rather than being offered (marketed or sold) that service, that's okay. (AFAIK)
As for the dynamic experience, that's what I meant about it needing to be a "fork"... because you then need a client development project, and once you are changing the client, it's "not the same game". (apparently :lol:) You could do it "off-line" via a launcher. You would probably also find that a normal client would DC players if the server started telling it it's Exp was all wrong. :wink:
Those that add new functionality must also add new code =PQuote:
Originally Posted by bobsobol
This look like interesting project and since you are providing "space" you can name server whatever you like but I would call it OPT, OpenPT or DPT, DatabasePT since you planing to move "everything" to database ;)
I just wanted to ask if this will be something like rPT? PT code rewritten to source and injected as .dll?
Ofc. I just keep thinking that you shouldn't have to change the source and recompile the DLL to fit it to a different client.Quote:
Originally Posted by Vormav
I understand why you have done it this way, and a couple of attempts at avoiding that have illustrated to me how hard it is to avoid. But it's still a downfall. The most successful method was adding "exports" to the client executable which the DLL picked up on and used... but there aren't any convenient tools to do that, and it's a major hex job which is actually *way* more work than changing the source and recompiling. XD
Another, and easier, idea I have for 2 way communication is something similar to the old TSR API tables in OS like DOS / CP/M / TOS / Amiga OS etc. The way they work is that each API has an index in a jump table. When it is called it is called by the address at it's index in the jump table. (not dis-similar to PE Exports, except that the addresses are a linear array, not a pointer to a pointer) An "override" API (code to be run before, after, or instead) will modify the jump table to point to it's code. If it is "instead", job done. If it should happen *before* the usual code, then it records the old pointer internally, does it's stuff and then jumps to the old pointer. If it should run after, then it does the same, but rather calls the old pointer before doing it's new stuff.
This method enables multiple overrides, since each override routine will record the address of the last one to patch that routine and call it as if it where the original. ^_^
Nice for code.
The problem with your DLLs is more the Data offsets in the executable. If they are recorded in a table (perhaps in a new section you add to the client executable) then they should not be altered, the way code pointers would.
All of this involves modifying the client and... as I said, your base server should not require you to do that. (ideally) Some of it may be possible with an "in memory" patcher. But making that intelligent enough to fit any client will be quite difficult. Just passing out an added section of pointers to add to the executable would be quite doable, and something some people could get into doing on a regular basis. It's a challenge, but repetition makes it easier. :wink:
Initially i plan to have the server completely rewritten but the client will obviously have to rely on a build up of dll's until we manage to get more object orientated programmers who know the ins and outs of fully implementing a 3d mesh interface. But then i guess when it comes to that you might as well really just write your own complete game and just model it around a more efficient and up to date version of PT. I have no issues about changing the name, as i said what i put there was only so i could get a working frame up and not look empty.
Actually, implementing the 3D meshes in the server are the primary downfall of every server emulator we have, and several I know of in private development. (never released)
You can throw a 3D engine (pre-made FOSS one) into any game client and it will JFW. (Just flippin' work) But getting 3D implemented in the server so AIs work and your don't float through things and stuff is much more difficult because most engines don't support "bounding boxes" in multiple 3D spaces which are never rendered. :(:
+1 zuz :D! send me your msn please bro i need to talk to you...