2019-08-19 18:39:33 +00:00
|
|
|
#include <components/openmw-mp/TimedLog.hpp>
|
2018-06-07 09:49:12 +00:00
|
|
|
|
|
|
|
|
#include "../mwbase/environment.hpp"
|
|
|
|
|
|
|
|
|
|
#include "../mwgui/windowmanagerimp.hpp"
|
|
|
|
|
|
2019-10-08 08:09:08 +00:00
|
|
|
#include "../mwmechanics/mechanicsmanagerimp.hpp"
|
|
|
|
|
|
[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.
2018-07-21 02:20:26 +00:00
|
|
|
#include "../mwworld/player.hpp"
|
2018-06-07 09:49:12 +00:00
|
|
|
#include "../mwworld/worldimp.hpp"
|
|
|
|
|
|
2018-05-27 12:57:47 +00:00
|
|
|
#include "Worldstate.hpp"
|
|
|
|
|
#include "Main.hpp"
|
|
|
|
|
#include "Networking.hpp"
|
2020-08-16 21:56:01 +00:00
|
|
|
#include "PlayerList.hpp"
|
|
|
|
|
#include "DedicatedPlayer.hpp"
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
#include "RecordHelper.hpp"
|
2020-08-16 21:56:01 +00:00
|
|
|
#include "CellController.hpp"
|
2018-05-27 12:57:47 +00:00
|
|
|
|
|
|
|
|
using namespace mwmp;
|
|
|
|
|
|
|
|
|
|
Worldstate::Worldstate()
|
|
|
|
|
{
|
2018-05-27 13:05:40 +00:00
|
|
|
hasPlayerCollision = true;
|
|
|
|
|
hasActorCollision = true;
|
|
|
|
|
hasPlacedObjectCollision = false;
|
|
|
|
|
useActorCollisionForPlacedObjects = false;
|
2018-05-27 12:57:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Worldstate::~Worldstate()
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Networking *Worldstate::getNetworking()
|
|
|
|
|
{
|
|
|
|
|
return mwmp::Main::get().getNetworking();
|
|
|
|
|
}
|
2018-06-07 09:49:12 +00:00
|
|
|
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
void Worldstate::addRecords()
|
|
|
|
|
{
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Received ID_RECORD_DYNAMIC with %i records of type %i",
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
recordsCount, recordsType);
|
|
|
|
|
|
|
|
|
|
if (recordsType == mwmp::RECORD_TYPE::SPELL)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : spellRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- spell record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::POTION)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : potionRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- potion record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::ENCHANTMENT)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : enchantmentRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- enchantment record %s, %i\n-- baseId is %s", record.data.mId.c_str(), record.data.mData.mType,
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::CREATURE)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : creatureRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- creature record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::NPC)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : npcRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- NPC record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::ARMOR)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : armorRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- armor record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::BOOK)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : bookRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- book record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::CLOTHING)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : clothingRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- clothing record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::MISCELLANEOUS)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : miscellaneousRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- miscellaneous record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::WEAPON)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : weaponRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- weapon record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-07-27 00:45:50 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::CONTAINER)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : containerRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- container record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-07-27 00:45:50 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-07-27 00:45:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::DOOR)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : doorRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- door record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-07-27 00:45:50 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-07-27 00:45:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-08-01 06:48:57 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::ACTIVATOR)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : activatorRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- activator record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-01 06:48:57 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-01 06:48:57 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::STATIC)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : staticRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- static record %s\n-- baseId is %s", record.data.mId.c_str(),
|
2019-08-01 06:48:57 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-01 06:48:57 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-08-03 03:19:22 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::INGREDIENT)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : ingredientRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- ingredient record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-03 03:19:22 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-03 03:19:22 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-08-04 14:53:18 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::APPARATUS)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : apparatusRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- apparatus record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-04 14:53:18 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-04 14:53:18 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::LOCKPICK)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : lockpickRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- lockpick record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-04 14:53:18 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-04 14:53:18 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::PROBE)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : probeRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- probe record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-04 14:53:18 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-04 14:53:18 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::REPAIR)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : repairRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- repair record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-04 14:53:18 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-04 14:53:18 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-08-14 18:10:53 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::LIGHT)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : lightRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- light record %s, %s\n-- baseId is %s", record.data.mId.c_str(), record.data.mName.c_str(),
|
2019-08-14 18:10:53 +00:00
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-08-14 18:10:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-09-28 10:12:48 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::CELL)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : cellRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
|
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- cell record %s\n-- baseId is %s", record.data.mName.c_str(),
|
|
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
2019-10-16 15:05:52 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
2019-09-28 10:12:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-11-09 19:34:09 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::SCRIPT)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : scriptRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
|
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- script record %s\n-- baseId is %s", record.data.mId.c_str(),
|
|
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
|
|
|
|
RecordHelper::overrideRecord(record);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-29 12:06:17 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::BODYPART)
|
|
|
|
|
{
|
|
|
|
|
for (auto &&record : bodyPartRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
|
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- bodypart record %s\n-- baseId is %s", record.data.mId.c_str(),
|
|
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
|
|
|
|
|
|
|
|
|
RecordHelper::overrideRecord(record);
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-03-15 18:17:00 +00:00
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::SOUND)
|
|
|
|
|
{
|
2020-08-11 16:33:12 +00:00
|
|
|
for (auto&& record : soundRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
2020-03-15 18:17:00 +00:00
|
|
|
|
2020-08-11 16:33:12 +00:00
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- sound record %s\n-- baseId is %s", record.data.mId.c_str(),
|
|
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
2021-07-18 09:36:07 +00:00
|
|
|
|
|
|
|
|
RecordHelper::overrideRecord(record);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (recordsType == mwmp::RECORD_TYPE::GAMESETTING)
|
|
|
|
|
{
|
|
|
|
|
for (auto&& record : gameSettingRecords)
|
|
|
|
|
{
|
|
|
|
|
bool hasBaseId = !record.baseId.empty();
|
|
|
|
|
|
|
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- gameSetting record %s\n-- baseId is %s", record.data.mId.c_str(),
|
|
|
|
|
hasBaseId ? record.baseId.c_str() : "empty");
|
2020-03-15 18:17:00 +00:00
|
|
|
|
2020-08-11 16:33:12 +00:00
|
|
|
RecordHelper::overrideRecord(record);
|
|
|
|
|
}
|
2020-03-15 18:17:00 +00:00
|
|
|
}
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
}
|
|
|
|
|
|
2018-06-24 23:34:11 +00:00
|
|
|
bool Worldstate::containsExploredMapTile(int cellX, int cellY)
|
|
|
|
|
{
|
|
|
|
|
for (const auto &mapTile : exploredMapTiles)
|
|
|
|
|
{
|
|
|
|
|
if (mapTile.x == cellX && mapTile.y == cellY)
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::markExploredMapTile(int cellX, int cellY)
|
|
|
|
|
{
|
|
|
|
|
mwmp::MapTile exploredTile;
|
|
|
|
|
exploredTile.x = cellX;
|
|
|
|
|
exploredTile.y = cellY;
|
|
|
|
|
exploredMapTiles.push_back(exploredTile);
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-04 07:56:37 +00:00
|
|
|
void Worldstate::setClientGlobals()
|
|
|
|
|
{
|
|
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Received ID_CLIENT_SCRIPT_GLOBAL with the following global values:");
|
|
|
|
|
std::string debugMessage = "";
|
|
|
|
|
|
|
|
|
|
for (const auto &clientGlobal : clientGlobals)
|
|
|
|
|
{
|
|
|
|
|
if (TimedLog::GetLevel() <= TimedLog::LOG_INFO)
|
|
|
|
|
{
|
|
|
|
|
if (!debugMessage.empty())
|
|
|
|
|
debugMessage += ", ";
|
|
|
|
|
|
2020-02-17 16:19:03 +00:00
|
|
|
std::string variableTypeAsString;
|
|
|
|
|
std::string valueAsString;
|
|
|
|
|
|
|
|
|
|
if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::SHORT || clientGlobal.variableType == mwmp::VARIABLE_TYPE::LONG)
|
|
|
|
|
{
|
|
|
|
|
variableTypeAsString = clientGlobal.variableType == mwmp::VARIABLE_TYPE::SHORT ? "short" : "long";
|
|
|
|
|
valueAsString = std::to_string(clientGlobal.intValue);
|
|
|
|
|
}
|
|
|
|
|
else if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::FLOAT)
|
|
|
|
|
{
|
|
|
|
|
variableTypeAsString = "float";
|
|
|
|
|
valueAsString = std::to_string(clientGlobal.floatValue);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
debugMessage += clientGlobal.id + ": " + variableTypeAsString + " " + valueAsString;
|
2020-01-04 07:56:37 +00:00
|
|
|
}
|
|
|
|
|
|
2021-01-25 23:07:35 +00:00
|
|
|
MWBase::World* world = MWBase::Environment::get().getWorld();
|
|
|
|
|
|
|
|
|
|
// If this global doesn't exist, create it
|
|
|
|
|
if (!world->hasGlobal(clientGlobal.id))
|
|
|
|
|
{
|
|
|
|
|
ESM::VarType varType;
|
|
|
|
|
|
|
|
|
|
if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::SHORT)
|
|
|
|
|
varType = ESM::VarType::VT_Short;
|
|
|
|
|
else if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::LONG)
|
|
|
|
|
varType = ESM::VarType::VT_Long;
|
|
|
|
|
if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::FLOAT)
|
|
|
|
|
varType = ESM::VarType::VT_Float;
|
|
|
|
|
|
|
|
|
|
world->createGlobal(clientGlobal.id, varType);
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-17 16:19:03 +00:00
|
|
|
if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::SHORT || clientGlobal.variableType == mwmp::VARIABLE_TYPE::LONG)
|
2021-01-25 23:07:35 +00:00
|
|
|
world->setGlobalInt(clientGlobal.id, clientGlobal.intValue);
|
2020-01-04 07:56:37 +00:00
|
|
|
else if (clientGlobal.variableType == mwmp::VARIABLE_TYPE::FLOAT)
|
2021-01-25 23:07:35 +00:00
|
|
|
world->setGlobalFloat(clientGlobal.id, clientGlobal.floatValue);
|
2020-01-04 07:56:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- %s", debugMessage.c_str());
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-08 08:09:08 +00:00
|
|
|
void Worldstate::setKills()
|
|
|
|
|
{
|
|
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Received ID_WORLD_KILL_COUNT with the following kill counts:");
|
|
|
|
|
std::string debugMessage = "";
|
|
|
|
|
|
|
|
|
|
for (const auto &killChange : killChanges)
|
|
|
|
|
{
|
|
|
|
|
if (TimedLog::GetLevel() <= TimedLog::LOG_INFO)
|
|
|
|
|
{
|
|
|
|
|
if (!debugMessage.empty())
|
|
|
|
|
debugMessage += ", ";
|
|
|
|
|
|
|
|
|
|
debugMessage += killChange.refId + ": " + std::to_string(killChange.number);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MWBase::Environment::get().getMechanicsManager()->setDeaths(killChange.refId, killChange.number);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LOG_APPEND(TimedLog::LOG_INFO, "- %s", debugMessage.c_str());
|
|
|
|
|
}
|
|
|
|
|
|
[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.
2018-07-21 02:20:26 +00:00
|
|
|
void Worldstate::setMapExplored()
|
|
|
|
|
{
|
|
|
|
|
for (const auto &mapTile : mapTiles)
|
|
|
|
|
{
|
|
|
|
|
const MWWorld::CellStore *cellStore = MWBase::Environment::get().getWorld()->getExterior(mapTile.x, mapTile.y);
|
|
|
|
|
|
|
|
|
|
if (!cellStore->getCell()->mName.empty())
|
|
|
|
|
MWBase::Environment::get().getWindowManager()->addVisitedLocation(cellStore->getCell()->mName, mapTile.x, mapTile.y);
|
|
|
|
|
|
|
|
|
|
MWBase::Environment::get().getWindowManager()->setGlobalMapImage(mapTile.x, mapTile.y, mapTile.imageData);
|
|
|
|
|
|
|
|
|
|
// Keep this tile marked as explored so we don't send any more packets for it
|
|
|
|
|
markExploredMapTile(mapTile.x, mapTile.y);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::setWeather()
|
|
|
|
|
{
|
|
|
|
|
MWBase::World *world = MWBase::Environment::get().getWorld();
|
|
|
|
|
|
|
|
|
|
// There's a chance we've been sent the weather for a region right after a teleportation
|
|
|
|
|
// that hasn't been registered in the WeatherManager yet, meaning the WeatherManager
|
|
|
|
|
// doesn't have the correct new region set for us, so make sure we update it
|
|
|
|
|
world->updateWeather(0);
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Setting weather for region: %s, currentWeather: %i, "
|
[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.
2018-07-21 02:20:26 +00:00
|
|
|
"nextWeather: %i, queuedWeather: %i, transitionFactor: %f, forceWeather is %s",
|
|
|
|
|
weather.region.c_str(), weather.currentWeather, weather.nextWeather,
|
|
|
|
|
weather.queuedWeather, weather.transitionFactor, forceWeather ? "true" : "false");
|
|
|
|
|
|
|
|
|
|
world->setRegionWeather(weather.region.c_str(), weather.currentWeather, weather.nextWeather,
|
|
|
|
|
weather.queuedWeather, weather.transitionFactor, forceWeather);
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-16 21:56:01 +00:00
|
|
|
void Worldstate::resetCells(std::vector<ESM::Cell>* cells)
|
|
|
|
|
{
|
|
|
|
|
MWBase::World* world = MWBase::Environment::get().getWorld();
|
|
|
|
|
|
|
|
|
|
bool haveUnloadedActiveCells = false;
|
|
|
|
|
ESM::Cell playerCell = *world->getPlayerPtr().getCell()->getCell();
|
|
|
|
|
ESM::Position playerPos = world->getPlayerPtr().getRefData().getPosition();
|
|
|
|
|
std::vector<RakNet::RakNetGUID> playersInCell;
|
|
|
|
|
|
|
|
|
|
for (auto cell : *cells)
|
|
|
|
|
{
|
|
|
|
|
if (!haveUnloadedActiveCells)
|
|
|
|
|
{
|
|
|
|
|
if (world->isCellActive(cell))
|
|
|
|
|
{
|
|
|
|
|
playersInCell = mwmp::PlayerList::getPlayersInCell(cell);
|
|
|
|
|
|
|
|
|
|
// If there are any DedicatedPlayers in this cell, also move them to the temporary holding interior cell
|
|
|
|
|
if (!playersInCell.empty())
|
|
|
|
|
{
|
|
|
|
|
for (RakNet::RakNetGUID otherGuid : playersInCell)
|
|
|
|
|
{
|
|
|
|
|
DedicatedPlayer* dedicatedPlayer = mwmp::PlayerList::getPlayer(otherGuid);
|
|
|
|
|
dedicatedPlayer->cell = *world->getInterior(RecordHelper::getPlaceholderInteriorCellName())->getCell();
|
|
|
|
|
dedicatedPlayer->setCell();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Change to temporary holding interior cell
|
|
|
|
|
world->changeToInteriorCell(RecordHelper::getPlaceholderInteriorCellName(), playerPos, true, true);
|
|
|
|
|
|
|
|
|
|
mwmp::Main::get().getCellController()->uninitializeCells();
|
|
|
|
|
world->unloadActiveCells();
|
|
|
|
|
|
|
|
|
|
haveUnloadedActiveCells = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
world->clearCellStore(cell);
|
|
|
|
|
|
|
|
|
|
for (RakNet::RakNetGUID otherGuid : playersInCell)
|
|
|
|
|
{
|
|
|
|
|
DedicatedPlayer* dedicatedPlayer = mwmp::PlayerList::getPlayer(otherGuid);
|
|
|
|
|
dedicatedPlayer->cell = cell;
|
|
|
|
|
dedicatedPlayer->setCell();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Move the player from their temporary holding cell to their previous cell
|
|
|
|
|
if (haveUnloadedActiveCells)
|
|
|
|
|
{
|
|
|
|
|
if (playerCell.isExterior())
|
|
|
|
|
world->changeToExteriorCell(playerPos, true, true);
|
|
|
|
|
else
|
|
|
|
|
world->changeToInteriorCell(playerCell.mName, playerPos, true, true);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-17 16:19:03 +00:00
|
|
|
void Worldstate::sendClientGlobal(std::string varName, int value, mwmp::VARIABLE_TYPE variableType)
|
2020-01-04 07:56:37 +00:00
|
|
|
{
|
|
|
|
|
clientGlobals.clear();
|
|
|
|
|
|
|
|
|
|
mwmp::ClientVariable clientVariable;
|
|
|
|
|
clientVariable.id = varName;
|
2020-02-17 16:19:03 +00:00
|
|
|
clientVariable.variableType = variableType;
|
2020-01-04 07:56:37 +00:00
|
|
|
clientVariable.intValue = value;
|
|
|
|
|
|
2020-02-17 16:19:03 +00:00
|
|
|
std::string variableTypeAsString;
|
|
|
|
|
|
|
|
|
|
if (variableType == mwmp::VARIABLE_TYPE::SHORT)
|
|
|
|
|
variableTypeAsString = "short";
|
|
|
|
|
else if (variableType == mwmp::VARIABLE_TYPE::LONG)
|
|
|
|
|
variableTypeAsString = "long";
|
|
|
|
|
|
|
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_CLIENT_SCRIPT_GLOBAL with name %s, type %s, value %i",
|
|
|
|
|
varName.c_str(), variableTypeAsString.c_str(), value);
|
2020-01-04 07:56:37 +00:00
|
|
|
|
|
|
|
|
clientGlobals.push_back(clientVariable);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_CLIENT_SCRIPT_GLOBAL)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_CLIENT_SCRIPT_GLOBAL)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::sendClientGlobal(std::string varName, float value)
|
|
|
|
|
{
|
|
|
|
|
clientGlobals.clear();
|
|
|
|
|
|
|
|
|
|
mwmp::ClientVariable clientVariable;
|
|
|
|
|
clientVariable.id = varName;
|
|
|
|
|
clientVariable.variableType = mwmp::VARIABLE_TYPE::FLOAT;
|
|
|
|
|
clientVariable.floatValue = value;
|
|
|
|
|
|
|
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_CLIENT_SCRIPT_GLOBAL with name %s, type float, value %f", varName.c_str(), value);
|
|
|
|
|
|
|
|
|
|
clientGlobals.push_back(clientVariable);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_CLIENT_SCRIPT_GLOBAL)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_CLIENT_SCRIPT_GLOBAL)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-24 23:34:11 +00:00
|
|
|
void Worldstate::sendMapExplored(int cellX, int cellY, const std::vector<char>& imageData)
|
2018-06-07 09:49:12 +00:00
|
|
|
{
|
2018-07-12 02:06:31 +00:00
|
|
|
mapTiles.clear();
|
2018-06-07 09:49:12 +00:00
|
|
|
|
|
|
|
|
mwmp::MapTile mapTile;
|
2018-06-24 23:34:11 +00:00
|
|
|
mapTile.x = cellX;
|
|
|
|
|
mapTile.y = cellY;
|
2018-06-07 09:49:12 +00:00
|
|
|
mapTile.imageData = imageData;
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_PLAYER_MAP with x: %i, y: %i", cellX, cellY);
|
2018-06-07 09:49:12 +00:00
|
|
|
|
2018-07-12 02:06:31 +00:00
|
|
|
mapTiles.push_back(mapTile);
|
2018-06-07 09:49:12 +00:00
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_WORLD_MAP)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_WORLD_MAP)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
[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.
2018-07-21 02:20:26 +00:00
|
|
|
void Worldstate::sendWeather(std::string region, int currentWeather, int nextWeather, int queuedWeather, float transitionFactor)
|
2018-06-07 09:49:12 +00:00
|
|
|
{
|
2018-07-21 02:21:26 +00:00
|
|
|
forceWeather = false;
|
[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.
2018-07-21 02:20:26 +00:00
|
|
|
weather.region = region;
|
|
|
|
|
weather.currentWeather = currentWeather;
|
|
|
|
|
weather.nextWeather = nextWeather;
|
|
|
|
|
weather.queuedWeather = queuedWeather;
|
|
|
|
|
weather.transitionFactor = transitionFactor;
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_PLAYER_WEATHER with region: %s, currentWeather: %i, "
|
[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.
2018-07-21 02:20:26 +00:00
|
|
|
"nextWeather: %i, queuedWeather, %i, transitionFactor: %f",
|
|
|
|
|
region.c_str(), currentWeather, nextWeather, queuedWeather, transitionFactor);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_WORLD_WEATHER)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_WORLD_WEATHER)->Send();
|
2018-06-07 09:49:12 +00:00
|
|
|
}
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
void Worldstate::sendEnchantmentRecord(const ESM::Enchantment* enchantment)
|
|
|
|
|
{
|
|
|
|
|
enchantmentRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with enchantment");
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::ENCHANTMENT;
|
|
|
|
|
|
|
|
|
|
mwmp::EnchantmentRecord record;
|
|
|
|
|
record.data = *enchantment;
|
|
|
|
|
enchantmentRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-22 19:21:30 +00:00
|
|
|
void Worldstate::sendPotionRecord(const ESM::Potion* potion, unsigned int quantity)
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
{
|
|
|
|
|
potionRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with potion %s", potion->mName.c_str());
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::POTION;
|
|
|
|
|
|
|
|
|
|
mwmp::PotionRecord record;
|
|
|
|
|
record.data = *potion;
|
2020-02-22 19:21:30 +00:00
|
|
|
record.quantity = quantity;
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
potionRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::sendSpellRecord(const ESM::Spell* spell)
|
|
|
|
|
{
|
|
|
|
|
spellRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with spell %s", spell->mName.c_str());
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::SPELL;
|
|
|
|
|
|
|
|
|
|
mwmp::SpellRecord record;
|
|
|
|
|
record.data = *spell;
|
|
|
|
|
spellRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::sendArmorRecord(const ESM::Armor* armor, std::string baseId)
|
|
|
|
|
{
|
|
|
|
|
armorRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with armor %s", armor->mName.c_str());
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::ARMOR;
|
|
|
|
|
|
|
|
|
|
mwmp::ArmorRecord record;
|
|
|
|
|
record.data = *armor;
|
|
|
|
|
record.baseId = baseId;
|
|
|
|
|
record.baseOverrides.hasName = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentId = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentCharge = true;
|
|
|
|
|
armorRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::sendBookRecord(const ESM::Book* book, std::string baseId)
|
|
|
|
|
{
|
|
|
|
|
bookRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with book %s", book->mName.c_str());
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::BOOK;
|
|
|
|
|
|
|
|
|
|
mwmp::BookRecord record;
|
|
|
|
|
record.data = *book;
|
|
|
|
|
record.baseId = baseId;
|
|
|
|
|
record.baseOverrides.hasName = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentId = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentCharge = true;
|
|
|
|
|
bookRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Worldstate::sendClothingRecord(const ESM::Clothing* clothing, std::string baseId)
|
|
|
|
|
{
|
|
|
|
|
clothingRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with clothing %s", clothing->mName.c_str());
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::CLOTHING;
|
|
|
|
|
|
|
|
|
|
mwmp::ClothingRecord record;
|
|
|
|
|
record.data = *clothing;
|
|
|
|
|
record.baseId = baseId;
|
|
|
|
|
record.baseOverrides.hasName = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentId = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentCharge = true;
|
|
|
|
|
clothingRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-19 20:17:09 +00:00
|
|
|
void Worldstate::sendWeaponRecord(const ESM::Weapon* weapon, std::string baseId, unsigned int quantity)
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
{
|
|
|
|
|
weaponRecords.clear();
|
|
|
|
|
|
2019-08-19 18:39:33 +00:00
|
|
|
LOG_MESSAGE_SIMPLE(TimedLog::LOG_INFO, "Sending ID_RECORD_DYNAMIC with weapon %s", weapon->mName.c_str());
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
|
|
|
|
|
recordsType = mwmp::RECORD_TYPE::WEAPON;
|
|
|
|
|
|
|
|
|
|
mwmp::WeaponRecord record;
|
|
|
|
|
record.data = *weapon;
|
2020-04-19 20:17:09 +00:00
|
|
|
record.quantity = quantity;
|
[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.
2018-07-30 07:56:26 +00:00
|
|
|
record.baseId = baseId;
|
|
|
|
|
record.baseOverrides.hasName = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentId = true;
|
|
|
|
|
record.baseOverrides.hasEnchantmentCharge = true;
|
|
|
|
|
weaponRecords.push_back(record);
|
|
|
|
|
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->setWorldstate(this);
|
|
|
|
|
getNetworking()->getWorldstatePacket(ID_RECORD_DYNAMIC)->Send();
|
|
|
|
|
}
|
