Structure

[noisiver]

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]

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]

@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]

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]

@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]

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

what is most important are things such as:

• people should not access gear items of later seasons, for example TBC or WOTLK items
• PvP vendors should be made like the first season of Vanilla, it should not be possible to buy stronger PvP items

[noisiver]

@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]

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

[locus313]

@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]

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

[alchem1ster]

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]

@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]

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.