You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
openmw-tes3mp/components/openmw-mp/Base/BaseWorldstate.hpp

240 lines
5.7 KiB
C++

#ifndef OPENMW_BASEWORLDSTATE_HPP
#define OPENMW_BASEWORLDSTATE_HPP
#include <vector>
[General] Implement RecordDynamic packet, part 1 Spell, potion, enchantment, creature, NPC, armor, book, clothing, miscellaneous and weapon record data can now be sent in a RecordDynamic packet. Additionally, the packets include data related to associated magical effects (for spells, potions and enchantments), data related to default inventory contents (for creatures and NPCs) and data related to body parts affected (for armor and clothing). The server now has associated script functions for setting most of the details of the above, with the main exception being individual creature and NPC stats. Records can either be created entirely from scratch or can use an existing record (set via the baseId variable) as a starting point for their values. In the latter case, only the values that are specifically set override the starting values. Creature and NPC records also have an inventoryBaseId that can be used on top of the baseId to base their inventories on another existing record. The client's RecordHelper class has been heavily expanded to allow for the above mentioned functionality. When players create spells, potions and enchantments as part of regular gameplay, they send RecordDynamic packets that provide the server with the complete details of the records that should be created. When they create enchantments, they also provide the server with armor, book, clothing and weapon records corresponding to the items they've enchanted. This functionality added by this packet was originally supposed to be exclusive to the rewrite, but I've gone ahead and tried to provide it for the pre-rewrite in a way that can mostly be reused for the rewrite.
7 years ago
#include <components/esm/loadalch.hpp>
#include <components/esm/loadarmo.hpp>
#include <components/esm/loadbook.hpp>
#include <components/esm/loadclot.hpp>
#include <components/esm/loadcrea.hpp>
#include <components/esm/loadench.hpp>
#include <components/esm/loadmisc.hpp>
#include <components/esm/loadnpc.hpp>
#include <components/esm/loadspel.hpp>
#include <components/esm/loadweap.hpp>
#include <components/openmw-mp/Base/BaseStructs.hpp>
#include <RakNetTypes.h>
namespace mwmp
{
[General] Implement RecordDynamic packet, part 1 Spell, potion, enchantment, creature, NPC, armor, book, clothing, miscellaneous and weapon record data can now be sent in a RecordDynamic packet. Additionally, the packets include data related to associated magical effects (for spells, potions and enchantments), data related to default inventory contents (for creatures and NPCs) and data related to body parts affected (for armor and clothing). The server now has associated script functions for setting most of the details of the above, with the main exception being individual creature and NPC stats. Records can either be created entirely from scratch or can use an existing record (set via the baseId variable) as a starting point for their values. In the latter case, only the values that are specifically set override the starting values. Creature and NPC records also have an inventoryBaseId that can be used on top of the baseId to base their inventories on another existing record. The client's RecordHelper class has been heavily expanded to allow for the above mentioned functionality. When players create spells, potions and enchantments as part of regular gameplay, they send RecordDynamic packets that provide the server with the complete details of the records that should be created. When they create enchantments, they also provide the server with armor, book, clothing and weapon records corresponding to the items they've enchanted. This functionality added by this packet was originally supposed to be exclusive to the rewrite, but I've gone ahead and tried to provide it for the pre-rewrite in a way that can mostly be reused for the rewrite.
7 years ago
enum RECORD_TYPE
{
ARMOR,
BOOK,
CLOTHING,
CREATURE,
ENCHANTMENT,
MISCELLANEOUS,
NPC,
POTION,
SPELL,
WEAPON
};
// When using an existing record as a base, this struct tracks which changes
// need to be made to it
//
// Note: These can't be replaced with checks for empty strings or numerical
// values of 0 because you want to be able to blank out strings or
// set values of 0 through overrides, i.e. if someone is in the
// Mages Guild faction, you want to be able to remove them from it
// by using a blank faction string as an override
//
// There are, however, a few values that are not allowed to be blanked
// out in a record, such as races or classes for NPCs, and those
// should rely on checks for empty strings instead of having a
// boolean here
struct BaseOverrides
{
bool hasSubtype = false;
bool hasName = false;
bool hasModel = false;
bool hasIcon = false;
bool hasScript = false;
bool hasEnchantmentId = false;
bool hasEnchantmentCharge = false;
bool hasEffects = false;
bool hasBodyParts = false;
bool hasInventory = false;
bool hasAutoCalc = false;
bool hasCharge = false;
bool hasCost = false;
bool hasFlags = false;
bool hasValue = false;
bool hasWeight = false;
bool hasArmorRating = false;
bool hasHealth = false;
bool hasDamageChop = false;
bool hasDamageSlash = false;
bool hasDamageThrust = false;
bool hasReach = false;
bool hasSpeed = false;
bool hasKeyState = false;
bool hasScrollState = false;
bool hasSkillId = false;
bool hasText = false;
bool hasHair = false;
bool hasHead = false;
bool hasGender = false;
bool hasFaction = false;
bool hasLevel = false;
bool hasMagicka = false;
bool hasFatigue = false;
bool hasAiFight = false;
[General] Implement RecordDynamic packet, part 1 Spell, potion, enchantment, creature, NPC, armor, book, clothing, miscellaneous and weapon record data can now be sent in a RecordDynamic packet. Additionally, the packets include data related to associated magical effects (for spells, potions and enchantments), data related to default inventory contents (for creatures and NPCs) and data related to body parts affected (for armor and clothing). The server now has associated script functions for setting most of the details of the above, with the main exception being individual creature and NPC stats. Records can either be created entirely from scratch or can use an existing record (set via the baseId variable) as a starting point for their values. In the latter case, only the values that are specifically set override the starting values. Creature and NPC records also have an inventoryBaseId that can be used on top of the baseId to base their inventories on another existing record. The client's RecordHelper class has been heavily expanded to allow for the above mentioned functionality. When players create spells, potions and enchantments as part of regular gameplay, they send RecordDynamic packets that provide the server with the complete details of the records that should be created. When they create enchantments, they also provide the server with armor, book, clothing and weapon records corresponding to the items they've enchanted. This functionality added by this packet was originally supposed to be exclusive to the rewrite, but I've gone ahead and tried to provide it for the pre-rewrite in a way that can mostly be reused for the rewrite.
7 years ago
};
struct ArmorRecord
{
ESM::Armor data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct BookRecord
{
ESM::Book data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct ClothingRecord
{
ESM::Clothing data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct CreatureRecord
{
ESM::Creature data;
std::string baseId;
std::string inventoryBaseId;
std::vector<mwmp::Item> inventory;
BaseOverrides baseOverrides;
};
struct EnchantmentRecord
{
ESM::Enchantment data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct MiscellaneousRecord
{
ESM::Miscellaneous data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct NpcRecord
{
ESM::NPC data;
std::string baseId;
std::string inventoryBaseId;
std::vector<mwmp::Item> inventory;
BaseOverrides baseOverrides;
};
struct PotionRecord
{
ESM::Potion data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct SpellRecord
{
ESM::Spell data;
std::string baseId;
BaseOverrides baseOverrides;
};
struct WeaponRecord
{
ESM::Weapon data;
std::string baseId;
BaseOverrides baseOverrides;
};
static const int maxImageDataSize = 1800;
struct MapTile
{
int x;
int y;
std::vector<char> imageData;
};
[General] Reimplement weather synchronization to allow soft transitions Although weather sync was added by Koncord to the rewrite in fd721143e226061d72f7b8931b8d4192a5327f47 in a way that used surprisingly few lines of code, it relied on the server requesting weather states every second from authority players and sending them to non-authority players, while also allowing only very sudden weather transitions across regions, i.e. if there was one player in the Ascadian Isles who had stormy weather, and another player with clear weather in the Bitter Coast Region walked across to the Ascadian Isles, that player was instantly made to have stormy weather with no kind of transition at all. My approach solves both of those problems. It solves the packet spam by only sending weather updates to the server when weather changes happen or when there are new arrivals to a weather authority's region, and it allows for both sudden weather transitions when players teleport to a region and for soft, gradual transitions when players walk across to a region. It is inspired by my previous actor sync, and uses a WorldRegionAuthority packet to set players as region authorities in a similar way to how ActorAuthority sets players as cell AI authorities. Weather changes are created only by the region authority for a given region, and weather packets are also only sent by that authority. However, it should be noted that gradual weather transitions are used by default in this implementation. To use sudden weather transitions, the serverside Lua scripts need to forward WorldWeather packets with the forceWeather boolean set to true. That is, however, already handled by our default Lua scripts in situations where it makes sense.
7 years ago
struct Weather
{
std::string region;
unsigned int currentWeather;
unsigned int nextWeather;
unsigned int queuedWeather;
float transitionFactor;
};
class BaseWorldstate
{
public:
BaseWorldstate()
{
time.year = -1;
time.month = -1;
time.day = -1;
time.hour = -1;
time.daysPassed = -1;
time.timeScale = -1;
}
RakNet::RakNetGUID guid;
mwmp::Time time;
bool hasPlayerCollision;
bool hasActorCollision;
bool hasPlacedObjectCollision;
bool useActorCollisionForPlacedObjects;
std::string authorityRegion;
std::vector<std::string> enforcedCollisionRefIds;
std::vector<MapTile> mapTiles;
[General] Reimplement weather synchronization to allow soft transitions Although weather sync was added by Koncord to the rewrite in fd721143e226061d72f7b8931b8d4192a5327f47 in a way that used surprisingly few lines of code, it relied on the server requesting weather states every second from authority players and sending them to non-authority players, while also allowing only very sudden weather transitions across regions, i.e. if there was one player in the Ascadian Isles who had stormy weather, and another player with clear weather in the Bitter Coast Region walked across to the Ascadian Isles, that player was instantly made to have stormy weather with no kind of transition at all. My approach solves both of those problems. It solves the packet spam by only sending weather updates to the server when weather changes happen or when there are new arrivals to a weather authority's region, and it allows for both sudden weather transitions when players teleport to a region and for soft, gradual transitions when players walk across to a region. It is inspired by my previous actor sync, and uses a WorldRegionAuthority packet to set players as region authorities in a similar way to how ActorAuthority sets players as cell AI authorities. Weather changes are created only by the region authority for a given region, and weather packets are also only sent by that authority. However, it should be noted that gradual weather transitions are used by default in this implementation. To use sudden weather transitions, the serverside Lua scripts need to forward WorldWeather packets with the forceWeather boolean set to true. That is, however, already handled by our default Lua scripts in situations where it makes sense.
7 years ago
bool forceWeather;
Weather weather;
[General] Implement RecordDynamic packet, part 1 Spell, potion, enchantment, creature, NPC, armor, book, clothing, miscellaneous and weapon record data can now be sent in a RecordDynamic packet. Additionally, the packets include data related to associated magical effects (for spells, potions and enchantments), data related to default inventory contents (for creatures and NPCs) and data related to body parts affected (for armor and clothing). The server now has associated script functions for setting most of the details of the above, with the main exception being individual creature and NPC stats. Records can either be created entirely from scratch or can use an existing record (set via the baseId variable) as a starting point for their values. In the latter case, only the values that are specifically set override the starting values. Creature and NPC records also have an inventoryBaseId that can be used on top of the baseId to base their inventories on another existing record. The client's RecordHelper class has been heavily expanded to allow for the above mentioned functionality. When players create spells, potions and enchantments as part of regular gameplay, they send RecordDynamic packets that provide the server with the complete details of the records that should be created. When they create enchantments, they also provide the server with armor, book, clothing and weapon records corresponding to the items they've enchanted. This functionality added by this packet was originally supposed to be exclusive to the rewrite, but I've gone ahead and tried to provide it for the pre-rewrite in a way that can mostly be reused for the rewrite.
7 years ago
unsigned short recordsType;
unsigned int recordsCount;
std::vector<ArmorRecord> armorRecords;
std::vector<BookRecord> bookRecords;
std::vector<ClothingRecord> clothingRecords;
std::vector<CreatureRecord> creatureRecords;
std::vector<EnchantmentRecord> enchantmentRecords;
std::vector<MiscellaneousRecord> miscellaneousRecords;
std::vector<NpcRecord> npcRecords;
std::vector<PotionRecord> potionRecords;
std::vector<SpellRecord> spellRecords;
std::vector<WeaponRecord> weaponRecords;
bool isValid;
};
}
#endif //OPENMW_BASEWORLDSTATE_HPP