search

azerothcore / mod-progression-system

ChromieCraft Progression System
GNU Affero General Public License v3.0
59 stars 56 forks source link

Structure #4

Open noisiver opened 3 years ago

noisiver commented 3 years ago

It would be greatly appreciated to have some sort of structure of how the creation of this system should be set up

For instance, should the first 'phase' be 1.2, the second 1.3 and so on for each patch or is the first one straight up vanilla? And what folders should be used for what patch etc

I already started working on a system like this but I can't just copy everything over or it'll be hated by someone I'm sure. You can see it here

Another question is handling things that are not scripted in AC. I have handled Lord Kazzak in Blasted Lands myself by use of a module

Any input on this is appreciated

locus313 commented 3 years ago

My thought on the structure is to have it more level-based vs patch-based. It should be similar to the progress layout we are trying to do with ChromieCraft https://www.chromiecraft.com/progression/

I think we mainly want to have db only changes within this progression-system repo. Additional scripted bosses probably should be in separate modules.

unless @FrancescoBorzi has something different in mind.

noisiver commented 3 years ago

@locus313 I see. So in theory, patch-based mixed in with the levels. So me focusing a bit on patch-related changes is not totally invalid then, it's easy enough to move things I create to the correct level-range before I even submit it.

Could someone possible create directories that are required? The current PRs use zero/file but that seems invalid in that case. It should be something that sorts from top to bottom, right? It should at least have a preceding number in the name of the folder so it sorts correctly, users shouldn't have to scroll through and find the one they need, or am I wrong here?

I'm just trying to do what I can to create what is expected from me so it fits in with ACs idea of progression 👍

FrancescoBorzi commented 3 years ago

My thought on the structure is to have it more level-based vs patch-based. It should be similar to the progress layout we are trying to do with ChromieCraft https://www.chromiecraft.com/progression/

I think we mainly want to have db only changes within this progression-system repo. Additional scripted bosses probably should be in separate modules.

unless @FrancescoBorzi has something different in mind.

I confirm.

@tkn963 our efforts are currently focused on ChromieCraft, the child-project of AzerothCore. It has proven to be a big resource for AzerothCore providing tons of bug reports, financial help and attracting new contributors to AC. This is why we want to do our best to keep ChromieCraft great. As long as ChromieCraft prospers, AzerothCore will prosper as well.

noisiver commented 3 years ago

@FrancescoBorzi How perfect does the result have to be? Like my work on changing mounts to be like in vanilla for a pre-tbc set up of the progression, is that sort of thinking pointless? The same question could be asked about world bosses and so on, of course.

FrancescoBorzi commented 3 years ago

@tkn963 I did not think about mounts so I'm not really sure about it. World bosses should not be there until:

image

what is most important are things such as:

noisiver commented 3 years ago

@FrancescoBorzi Yes but certain world bosses are added in different patches, but they should all fall under the same level range no matter what?

I apologize for all the questions but I just don't wanna waste peoples time by making a ton of mistakes :P

FrancescoBorzi commented 3 years ago

@tkn963 no worries, questions are always welcome. Yes that is what we had in mind

locus313 commented 3 years ago

@tkn963 I did end up adding a 0 folder. Think it just makes a little more sense that the initial disables/changes are in the 0 folder. Then starting with the 1-19 folder is when we start to unlock things.

noisiver commented 3 years ago

@locus313 Gotcha, I'll move everything I've done so far into that folder then

alchem1ster commented 3 years ago

Guys, my suggestion might be absurd, but what if we thought about how it could be simplified. For example, for each Item/Gobj/NPC/Instance and others, we would get information about the patch in which they were added to the game (via parsing wowhead or another db). Then, we add this patch version to the database for each of them. Next, we put a hook in all the functions that load entities from the database and check the current worldserver patch (via some variable) against what's in the database. This way no entities will be loaded into the game world whose addition patch is higher than the one we set in the comparison variable. How impossible is that?

noisiver commented 3 years ago

@alchem1ster The suggestion is more or less how vMaNGOS works. You set the desired patch in the config file and the server only load things that are within the set patch. I was looking into this but the consensus was it's better to have it separate from the server to make it.. I don't know, modular? I can't remember specifically what the idea was.

Because of that I was working on a module for AC that handles everything but there are certain functions missing for a module to be fully functional - like handle changing costs of trainer spells, removing spells from trainers etc.

This is as far as I got before calling it quits due to this reason: https://github.com/tkn963/progression/tree/58d0f9277b1636f9d05291d44e54e28f79eae995

noisiver commented 3 years ago

My idea was that a module shouldn't alter the database at all, so a user could easily remove the module and everything would be back to normal. The way I was doing it was to delete creatures, objects etc from memory so it doesn't exist but the regular database goes untouched. That is my dream picture of a progression module.