OpenFusion/src/Combat.hpp

#pragma once

#include "Player.hpp"
#include "MobAI.hpp"

#include <map>
#include <vector>

struct Bullet {
    int pointDamage;
    int groupDamage;
    bool weaponBoost;
    int bulletType;
};

namespace Combat {
    extern std::map<int32_t, std::map<int8_t, Bullet>> Bullets;

    void init();

    void npcAttackPc(Mob *mob, time_t currTime);
    void genQItemRolls(std::vector<Player*> players, std::map<int, int>& rolls);
}
[refactor] Split MobManager.cpp into MobAI.cpp and Combat.cpp This is terrible. It was a mistake to do this before cleaning up the actual code. It might be better not to use this commit and to do this refactor in a different order or something. 2021-03-13 22:55:16 +00:00			`#pragma once`

The great re-`#include` Was getting frustrated by the inconsistency in our include statements, which were causing me problems. As a result, I went through and manually re-organized every include statement in non-core files. I'm just gonna copy my rant from Discord: FOR HEADER FILES (.hpp): - everything you use IN THE HEADER must be EXPLICITLY INCLUDED with the exception of things that fall under Core.hpp - you may NOT include ANYTHING ELSE FOR SOURCE FILES (.cpp): - you can #include whatever you want as long as the partner header is included first - anything that gets included by another include is fair game - redundant includes are ok because they'll be harmless AS LONG AS our header files stay lean. the point of this is NOT to optimize the number of includes used all around or make things more efficient necessarily. it's to improve readability & coherence and make it easier to avoid cyclical issues 2022-07-16 23:19:40 +00:00			`#include "Player.hpp"`
[refactor] Split MobManager.cpp into MobAI.cpp and Combat.cpp This is terrible. It was a mistake to do this before cleaning up the actual code. It might be better not to use this commit and to do this refactor in a different order or something. 2021-03-13 22:55:16 +00:00			`#include "MobAI.hpp"`

			`#include <map>`
The great re-`#include` Was getting frustrated by the inconsistency in our include statements, which were causing me problems. As a result, I went through and manually re-organized every include statement in non-core files. I'm just gonna copy my rant from Discord: FOR HEADER FILES (.hpp): - everything you use IN THE HEADER must be EXPLICITLY INCLUDED with the exception of things that fall under Core.hpp - you may NOT include ANYTHING ELSE FOR SOURCE FILES (.cpp): - you can #include whatever you want as long as the partner header is included first - anything that gets included by another include is fair game - redundant includes are ok because they'll be harmless AS LONG AS our header files stay lean. the point of this is NOT to optimize the number of includes used all around or make things more efficient necessarily. it's to improve readability & coherence and make it easier to avoid cyclical issues 2022-07-16 23:19:40 +00:00			`#include <vector>`
[refactor] Split MobManager.cpp into MobAI.cpp and Combat.cpp This is terrible. It was a mistake to do this before cleaning up the actual code. It might be better not to use this commit and to do this refactor in a different order or something. 2021-03-13 22:55:16 +00:00
			`struct Bullet {`
			`int pointDamage;`
			`int groupDamage;`
			`bool weaponBoost;`
			`int bulletType;`
			`};`

			`namespace Combat {`
			`extern std::map<int32_t, std::map<int8_t, Bullet>> Bullets;`

			`void init();`

			`void npcAttackPc(Mob *mob, time_t currTime);`
Refactor player groups Group structures are used now. Adds more checks in some places but simplifies things overall. We can expand this system to entities as well now pretty trivially. 2022-04-23 19:58:08 +00:00			`void genQItemRolls(std::vector<Player*> players, std::map<int, int>& rolls);`
[refactor] Split MobManager.cpp into MobAI.cpp and Combat.cpp This is terrible. It was a mistake to do this before cleaning up the actual code. It might be better not to use this commit and to do this refactor in a different order or something. 2021-03-13 22:55:16 +00:00			`}`