I suspect we need to coordinate an approach - my thoughts are:
1. Start with the current rev of eqemu and keep any changes required to "classic-ify" the code parameter driven and checked into the main code base so we're not creating a fork that will never get merged back into the main project.
2. Start with a current rev of PEQ and just create SQL patches to apply that if run sequentially will result in a "classic-ify'd' database. So for example the first giant SQL file for my database removes NPCs, doors, objects, items, etc. that are not Trilogy. This means that each revision of PEQ the project needs to ensure that the changes are applied but reviewed in case the change breaks something in the classic database. Publish the sql along with the eqemu code so if someone wants to 'classic'ify' their server they just apply that SQL in sequence to the current PEQ file.
3. Quests - open question, probably need to fork these entirely since I doubt any fixes made to quests are intended to revert them to classic.
So what I see happening is a project to create a release of the server as of March 16 1999. Next, a release as of the first significant patch (1999-09-21?) and so on. Each release would be a snapshot in time of the server, allowing server operators to follow actual timelines for releases of functions etc. to create a truly classic experience.
Regards,
Mg
|