Classic or era-based server content

[chrsschb]

We could all just wait for EQClassic to finally release.







(not srs, it'll never release)

[AdrianD]

That was good chrsschb, lol.

I'll just start something. If it needs to be changed, it can be changed.

[AdrianD]

I put some of my stuff here:

https://github.com/aduchaine/EQEmuCl...n/tree/AdrianD

There is likely a better place to put large tables and large amounts of data and I am open to advice.

I am new at the git stuff so please, suggest better methods.

Thanks

EDIT: I also don't care to have "ownership" of this stuff, and don't want it. If it can be set differently, please let me know.

[mgellan]

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

[provocating]

Originally Posted by mgellan

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.

I am not source control expert but I do not think this is viable. My source has gotten further and further custom. You have to think the current EqEmu source has code for instancing, AA's (cannot completely remove), bots, mercs, etc. Do you really want to keep all of that in there if it is not needed? I started stripping all of that out my first month with Legacy of FrostStone. I would want more streamlined code. When you are debugging there are a hell of a lot less lines of code when you take out routines that are not needed. If something cool comes to EqEmu source and I think it is needed I have added it to mine.

That being said I do not think you can merge back in if the changes are that drastic, sounds like a nightmare.

[mgellan]

Originally Posted by provocating

I am not source control expert but I do not think this is viable. My source has gotten further and further custom. You have to think the current EqEmu source has code for instancing, AA's (cannot completely remove), bots, mercs, etc. Do you really want to keep all of that in there if it is not needed?

Stripping code out by actually physically removing it is silly - better to have a compiler directive to just not compile that code in versus removing it. P99 have removed AA code - how can they do AAs now without laboriously reinserting the code? That being said I expect that the coders who are trying to get as close to Live as possible would be saying "No fucking way, keep that classic shit out of the code, it's complicated enough"

At the same time, if necessary I'd fork the code, keep applying updates and not change much so the code doesn't become so totally different than the main code base so as to preclude applying reasonable updates that would be useful in possible future expansions...

Regards,
Mg

[provocating]

Well we have two different directives. My code will never go past Velious.

[AdrianD]

I suspect we need to coordinate an approach

Yes, yes.

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.

I agree. What we do to customize our servers is our prerogative. My thought on this is to have a base for those interested in classic/progression.

[AdrianD]

This is getting bumped.

This deserves more attention.

Out of the woodwork!

Loosen the grip!

Lets get something done.

[jpyou127]

I agree whOle heartily!

[provocating]

If you are doing this by an Era by Era basis, like full progression then you are going to have to have a different quest pack for each era. After months of just reverting to Velious on my server I can tell you many quest are just flat out missing. Most are inaccurate with experience, mostly the newbie quest. We are still weeding out NPC's that out of era.

Drops rates are being changed on mob by mob basis, almost daily. Since it is unknown what they actually are. PEQ uses Magelo for drop rates but from my experience they are not accurate, even for the current era.

[AdrianD]

I can tell you many quest are just flat out missing

Perfection is impossible.

PEQ uses Magelo for drop rates but from my experience they are not accurate, even for the current era.

It's easy to drop any magelo generated loottable/lootdrop. There are quite a few of the above table entries that go unused which could be matched up with a bit of work.

It's also easy to drop all items outside of an expansion if those items are labelled with an expansion - like I have done for 60k+ items - so some of the magelo gen data dropping isn't necessary.

This is what I'm basically talking about. Getting the data proper in the database is huge as everyone has said. I've made some of it so simple a caveman can help!

[provocating]

I am pretty sure the Magelo issue has to lie with multiple items dropping off of creatures. Magelo drop rates do not show quantities so if a Crag Spider drops 8 silks, that would be a 800% drop rate on that one drop. I do not think Magelo's website ever shows above 100%

[AdrianD]

Originally Posted by provocating

I am pretty sure the Magelo issue has to lie with multiple items dropping off of creatures. Magelo drop rates do not show quantities so if a Crag Spider drops 8 silks, that would be a 800% drop rate on that one drop. I do not think Magelo's website ever shows above 100%

It seems that lootdrop.ids were added along with existing one when this was done. There are several columns in `loottable_entries` and `lootdrop_entries` which control this. <chance, multiplier, mindrop, probability> all of these combined create an environment that when you kill `a_large_rat` you get twelve items.

[AdrianD]

This is what I'm basically talking about. Getting the data proper in the database is huge as everyone has said. I've made some of it so simple a caveman can help!

To add:

I don't feel like carrying on and on about what I have done because I'm not an self-centered egomaniac like some. But, I also feel that I am doing a disservice to the segment of the community that wants classic/progression by not harping about what I have done (started).

It's very important to get these things (lootdrops, items, npcs, other database stuff) correct. I've spent about as much time developing my system as I have changing data (maybe not, but I said this for effect).

P99 has done it with whoever they have.

I see no fucking reason a much larger community can't!

Get with it...