1
0
mirror of https://gitlab.com/OpenMW/openmw.git synced 2025-01-25 06:35:30 +00:00
OpenMW/apps/openmw/mwscript/interpretercontext.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

494 lines
16 KiB
C++
Raw Normal View History

2010-07-02 18:08:00 +02:00
#include "interpretercontext.hpp"
2010-07-05 12:30:45 +02:00
#include <cmath>
#include <sstream>
2010-07-02 18:08:00 +02:00
#include <components/compiler/locals.hpp>
#include <components/esm/records.hpp>
2012-10-01 19:17:04 +04:00
#include "../mwworld/esmstore.hpp"
#include "../mwbase/environment.hpp"
#include "../mwbase/inputmanager.hpp"
#include "../mwbase/scriptmanager.hpp"
#include "../mwbase/windowmanager.hpp"
#include "../mwbase/world.hpp"
2019-02-22 23:16:47 +04:00
#include "../mwworld/action.hpp"
#include "../mwworld/cellstore.hpp"
#include "../mwworld/class.hpp"
2010-07-02 18:08:00 +02:00
#include "../mwmechanics/npcstats.hpp"
#include "globalscripts.hpp"
#include "locals.hpp"
2010-07-02 18:08:00 +02:00
namespace MWScript
{
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const MWWorld::Ptr InterpreterContext::getReferenceImp(const ESM::RefId& id, bool activeOnly, bool doThrow) const
{
if (!id.empty())
{
return MWBase::Environment::get().getWorld()->getPtr(id, activeOnly);
}
else
{
if (mReference.isEmpty() && mGlobalScriptDesc)
mReference = mGlobalScriptDesc->getPtr();
if (mReference.isEmpty() && doThrow)
throw MissingImplicitRefError();
return mReference;
}
}
const Locals& InterpreterContext::getMemberLocals(bool global, ESM::RefId& id) const
{
if (global)
{
return MWBase::Environment::get().getScriptManager()->getGlobalScripts().getLocals(id);
}
else
{
const MWWorld::Ptr ptr = getReferenceImp(id, false);
id = ptr.getClass().getScript(ptr);
2023-04-20 21:07:53 +02:00
ptr.getRefData().setLocals(*MWBase::Environment::get().getESMStore()->get<ESM::Script>().find(id));
return ptr.getRefData().getLocals();
}
}
Locals& InterpreterContext::getMemberLocals(bool global, ESM::RefId& id)
{
if (global)
{
return MWBase::Environment::get().getScriptManager()->getGlobalScripts().getLocals(id);
}
else
{
const MWWorld::Ptr ptr = getReferenceImp(id, false);
id = ptr.getClass().getScript(ptr);
2023-04-20 21:07:53 +02:00
ptr.getRefData().setLocals(*MWBase::Environment::get().getESMStore()->get<ESM::Script>().find(id));
return ptr.getRefData().getLocals();
}
}
MissingImplicitRefError::MissingImplicitRefError()
: std::runtime_error("no implicit reference")
{
}
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
int InterpreterContext::findLocalVariableIndex(const ESM::RefId& scriptId, std::string_view name, char type) const
{
int index = MWBase::Environment::get().getScriptManager()->getLocals(scriptId).searchIndex(type, name);
if (index != -1)
return index;
std::ostringstream stream;
stream << "Failed to access ";
switch (type)
{
case 's':
stream << "short";
break;
case 'l':
stream << "long";
break;
case 'f':
stream << "float";
break;
}
stream << " member variable " << name << " in script " << scriptId;
throw std::runtime_error(stream.str().c_str());
}
InterpreterContext::InterpreterContext(MWScript::Locals* locals, const MWWorld::Ptr& reference)
: mLocals(locals)
, mReference(reference)
{
}
InterpreterContext::InterpreterContext(std::shared_ptr<GlobalScriptDesc> globalScriptDesc)
: mLocals(&(globalScriptDesc->mLocals))
{
const MWWorld::Ptr* ptr = globalScriptDesc->getPtrIfPresent();
// A nullptr here signifies that the script's target has not yet been resolved after loading the game.
// Script targets are lazily resolved to MWWorld::Ptrs (which can, upon resolution, be empty)
// because scripts started through dialogue often don't use their implicit target.
if (ptr)
mReference = *ptr;
else
mGlobalScriptDesc = globalScriptDesc;
}
2010-07-02 18:08:00 +02:00
ESM::RefId InterpreterContext::getTarget() const
2021-02-14 16:25:38 +01:00
{
if (!mReference.isEmpty())
return mReference.mRef->mRef.getRefId();
else if (mGlobalScriptDesc)
return mGlobalScriptDesc->getId();
return ESM::RefId();
2021-02-14 16:25:38 +01:00
}
2010-07-02 18:08:00 +02:00
int InterpreterContext::getLocalShort(int index) const
{
if (!mLocals)
throw std::runtime_error("local variables not available in this context");
2010-07-02 18:08:00 +02:00
return mLocals->mShorts.at(index);
}
int InterpreterContext::getLocalLong(int index) const
{
if (!mLocals)
throw std::runtime_error("local variables not available in this context");
2010-07-02 18:08:00 +02:00
return mLocals->mLongs.at(index);
}
float InterpreterContext::getLocalFloat(int index) const
{
if (!mLocals)
throw std::runtime_error("local variables not available in this context");
2010-07-02 18:08:00 +02:00
return mLocals->mFloats.at(index);
}
void InterpreterContext::setLocalShort(int index, int value)
{
if (!mLocals)
throw std::runtime_error("local variables not available in this context");
mLocals->mShorts.at(index) = value;
}
void InterpreterContext::setLocalLong(int index, int value)
{
if (!mLocals)
throw std::runtime_error("local variables not available in this context");
mLocals->mLongs.at(index) = value;
2010-07-02 18:08:00 +02:00
}
void InterpreterContext::setLocalFloat(int index, float value)
{
if (!mLocals)
throw std::runtime_error("local variables not available in this context");
mLocals->mFloats.at(index) = value;
2010-07-02 18:08:00 +02:00
}
void InterpreterContext::messageBox(std::string_view message, const std::vector<std::string>& buttons)
2010-07-02 18:08:00 +02:00
{
if (buttons.empty())
MWBase::Environment::get().getWindowManager()->messageBox(message);
else
MWBase::Environment::get().getWindowManager()->interactiveMessageBox(message, buttons);
2010-07-02 18:08:00 +02:00
}
void InterpreterContext::report(const std::string& message) {}
int InterpreterContext::getGlobalShort(std::string_view name) const
{
return MWBase::Environment::get().getWorld()->getGlobalInt(name);
}
int InterpreterContext::getGlobalLong(std::string_view name) const
{
// a global long is internally a float.
return MWBase::Environment::get().getWorld()->getGlobalInt(name);
}
float InterpreterContext::getGlobalFloat(std::string_view name) const
{
return MWBase::Environment::get().getWorld()->getGlobalFloat(name);
}
void InterpreterContext::setGlobalShort(std::string_view name, int value)
{
2013-11-28 09:13:54 +01:00
MWBase::Environment::get().getWorld()->setGlobalInt(name, value);
}
void InterpreterContext::setGlobalLong(std::string_view name, int value)
{
2013-11-28 09:13:54 +01:00
MWBase::Environment::get().getWorld()->setGlobalInt(name, value);
}
void InterpreterContext::setGlobalFloat(std::string_view name, float value)
{
2013-11-28 09:13:54 +01:00
MWBase::Environment::get().getWorld()->setGlobalFloat(name, value);
}
std::vector<std::string> InterpreterContext::getGlobals() const
{
2023-04-20 21:07:53 +02:00
const MWWorld::Store<ESM::Global>& globals = MWBase::Environment::get().getESMStore()->get<ESM::Global>();
std::vector<std::string> ids;
for (const auto& globalVariable : globals)
{
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
ids.emplace_back(globalVariable.mId.getRefIdString());
}
return ids;
}
char InterpreterContext::getGlobalType(std::string_view name) const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
return world->getGlobalVariableType(name);
}
std::string InterpreterContext::getActionBinding(std::string_view targetAction) const
{
2014-12-20 14:46:11 -06:00
MWBase::InputManager* input = MWBase::Environment::get().getInputManager();
2022-08-12 18:42:12 +02:00
const auto& actions = input->getActionKeySorting();
for (const int action : actions)
{
2022-08-12 18:42:12 +02:00
std::string_view desc = input->getActionDescription(action);
if (desc.empty())
continue;
if (desc == targetAction)
2014-12-20 14:46:11 -06:00
{
if (input->joystickLastUsed())
return input->getActionControllerBindingName(action);
2014-12-20 14:46:11 -06:00
else
return input->getActionKeyBindingName(action);
2014-12-20 14:46:11 -06:00
}
}
return "None";
}
std::string_view InterpreterContext::getActorName() const
{
const MWWorld::Ptr& ptr = getReferenceImp();
if (ptr.getClass().isNpc())
{
const ESM::NPC* npc = ptr.get<ESM::NPC>()->mBase;
return npc->mName;
}
const ESM::Creature* creature = ptr.get<ESM::Creature>()->mBase;
return creature->mName;
}
std::string_view InterpreterContext::getNPCRace() const
{
const ESM::NPC* npc = getReferenceImp().get<ESM::NPC>()->mBase;
2023-04-20 21:07:53 +02:00
const ESM::Race* race = MWBase::Environment::get().getESMStore()->get<ESM::Race>().find(npc->mRace);
return race->mName;
}
std::string_view InterpreterContext::getNPCClass() const
{
const ESM::NPC* npc = getReferenceImp().get<ESM::NPC>()->mBase;
2023-04-20 21:07:53 +02:00
const ESM::Class* class_ = MWBase::Environment::get().getESMStore()->get<ESM::Class>().find(npc->mClass);
return class_->mName;
}
std::string_view InterpreterContext::getNPCFaction() const
{
const ESM::NPC* npc = getReferenceImp().get<ESM::NPC>()->mBase;
2023-04-20 21:07:53 +02:00
const ESM::Faction* faction = MWBase::Environment::get().getESMStore()->get<ESM::Faction>().find(npc->mFaction);
return faction->mName;
}
std::string_view InterpreterContext::getNPCRank() const
{
2015-01-27 17:32:21 +01:00
const MWWorld::Ptr& ptr = getReferenceImp();
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::RefId& faction = ptr.getClass().getPrimaryFaction(ptr);
2015-01-27 17:32:21 +01:00
if (faction.empty())
throw std::runtime_error("getNPCRank(): NPC is not in a faction");
2015-01-27 17:32:21 +01:00
int rank = ptr.getClass().getPrimaryFactionRank(ptr);
if (rank < 0 || rank > 9)
throw std::runtime_error("getNPCRank(): invalid rank");
MWBase::World* world = MWBase::Environment::get().getWorld();
const MWWorld::ESMStore& store = world->getStore();
2015-01-27 17:32:21 +01:00
const ESM::Faction* fact = store.get<ESM::Faction>().find(faction);
return fact->mRanks[rank];
}
std::string_view InterpreterContext::getPCName() const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
return world->getPlayerPtr().get<ESM::NPC>()->mBase->mName;
}
std::string_view InterpreterContext::getPCRace() const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::RefId& race = world->getPlayerPtr().get<ESM::NPC>()->mBase->mRace;
return world->getStore().get<ESM::Race>().find(race)->mName;
}
std::string_view InterpreterContext::getPCClass() const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::RefId& class_ = world->getPlayerPtr().get<ESM::NPC>()->mBase->mClass;
return world->getStore().get<ESM::Class>().find(class_)->mName;
}
std::string_view InterpreterContext::getPCRank() const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
MWWorld::Ptr player = world->getPlayerPtr();
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::RefId& factionId = getReferenceImp().getClass().getPrimaryFaction(getReferenceImp());
2015-01-27 17:32:21 +01:00
if (factionId.empty())
throw std::runtime_error("getPCRank(): NPC is not in a faction");
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const auto& ranks = player.getClass().getNpcStats(player).getFactionRanks();
auto it = ranks.find(factionId);
int rank = -1;
if (it != ranks.end())
rank = it->second;
// If you are not in the faction, PcRank returns the first rank, for whatever reason.
// This is used by the dialogue when joining the Thieves Guild in Balmora.
if (rank == -1)
rank = 0;
const MWWorld::ESMStore& store = world->getStore();
const ESM::Faction* faction = store.get<ESM::Faction>().find(factionId);
if (rank < 0 || rank > 9) // there are only 10 ranks
2022-08-12 18:42:12 +02:00
return {};
return faction->mRanks[rank];
}
std::string_view InterpreterContext::getPCNextRank() const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
MWWorld::Ptr player = world->getPlayerPtr();
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::RefId& factionId = getReferenceImp().getClass().getPrimaryFaction(getReferenceImp());
2015-01-27 17:32:21 +01:00
if (factionId.empty())
throw std::runtime_error("getPCNextRank(): NPC is not in a faction");
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const auto& ranks = player.getClass().getNpcStats(player).getFactionRanks();
auto it = ranks.find(factionId);
int rank = -1;
if (it != ranks.end())
rank = it->second;
++rank; // Next rank
2013-05-04 12:28:12 +02:00
// if we are already at max rank, there is no next rank
if (rank > 9)
rank = 9;
2013-05-04 12:28:12 +02:00
const MWWorld::ESMStore& store = world->getStore();
const ESM::Faction* faction = store.get<ESM::Faction>().find(factionId);
Some PVS-Studio and cppcheck fixes cppcheck: [apps/esmtool/record.cpp:697]: (performance) Prefer prefix ++/-- operators for non-primitive types. [apps/esmtool/record.cpp:1126]: (performance) Prefer prefix ++/-- operators for non-primitive types. [apps/esmtool/record.cpp:1138]: (performance) Prefer prefix ++/-- operators for non-primitive types. [apps/niftest/niftest.cpp:36]: (performance) Function parameter 'filename' should be passed by reference. [apps/niftest/niftest.cpp:41]: (performance) Function parameter 'filename' should be passed by reference. [apps/opencs/model/prefs/boolsetting.cpp:25]: (warning) Possible leak in public function. The pointer 'mWidget' is not deallocated before it is allocated. [apps/opencs/model/prefs/shortcuteventhandler.cpp:52]: (warning) Return value of std::remove() ignored. Elements remain in container. [apps/openmw/mwstate/quicksavemanager.cpp:5]: (performance) Variable 'mSaveName' is assigned in constructor body. Consider performing initialization in initialization list. PVS-Studio: apps/opencs/model/filter/parser.cpp 582 warn V560 A part of conditional expression is always true: allowPredefined. apps/opencs/view/world/referencecreator.cpp 67 warn V547 Expression '!errors.empty()' is always false. apps/opencs/view/world/referencecreator.cpp 74 warn V547 Expression '!errors.empty()' is always false. apps/opencs/view/doc/loader.cpp 170 warn V560 A part of conditional expression is always true: !completed. apps/opencs/view/doc/loader.cpp 170 warn V560 A part of conditional expression is always true: !error.empty(). apps/opencs/model/tools/pathgridcheck.cpp 32 err V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. Check lines: 32, 34. apps/opencs/model/world/refidadapterimp.cpp 1376 err V547 Expression 'subColIndex < 3' is always true. apps/openmw/mwgui/widgets.hpp 318 warn V703 It is odd that the 'mEnableRepeat' field in derived class 'MWScrollBar' overwrites field in base class 'ScrollBar'. Check lines: widgets.hpp:318, MyGUI_ScrollBar.h:179. apps/openmw/mwgui/widgets.hpp 319 warn V703 It is odd that the 'mRepeatTriggerTime' field in derived class 'MWScrollBar' overwrites field in base class 'ScrollBar'. Check lines: widgets.hpp:319, MyGUI_ScrollBar.h:180. apps/openmw/mwgui/widgets.hpp 320 warn V703 It is odd that the 'mRepeatStepTime' field in derived class 'MWScrollBar' overwrites field in base class 'ScrollBar'. Check lines: widgets.hpp:320, MyGUI_ScrollBar.h:181 apps/openmw/mwmechanics/actors.cpp 1425 warn V547 Expression '!detected' is always true. apps/openmw/mwmechanics/character.cpp 2155 err V547 Expression 'mode == 0' is always true. apps/openmw/mwmechanics/character.cpp 1192 warn V592 The expression was enclosed by parentheses twice: ((expression)). One pair of parentheses is unnecessary or misprint is present. apps/openmw/mwmechanics/character.cpp 521 warn V560 A part of conditional expression is always true: (idle == mIdleState). apps/openmw/mwmechanics/pathfinding.cpp 317 err V547 Expression 'mPath.size() >= 2' is always true. apps/openmw/mwscript/interpretercontext.cpp 409 warn V560 A part of conditional expression is always false: rank > 9. apps/openmw/mwgui/windowbase.cpp 28 warn V560 A part of conditional expression is always true: !visible. apps/openmw/mwgui/journalwindow.cpp 561 warn V547 Expression '!mAllQuests' is always false. apps/openmw/mwgui/referenceinterface.cpp 18 warn V571 Recurring check. The '!mPtr.isEmpty()' condition was already verified in line 16. apps/openmw/mwworld/scene.cpp 463 warn V547 Expression 'adjustPlayerPos' is always true. apps/openmw/mwworld/worldimp.cpp 409 err V766 An item with the same key '"sCompanionShare"' has already been added. apps/openmw/mwworld/cellstore.cpp 691 warn V519 The 'state.mWaterLevel' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 689, 691. apps/openmw/mwworld/weather.cpp 1125 warn V519 The 'mResult.mParticleEffect' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1123, 1125. apps/openmw/mwworld/weather.cpp 1137 warn V519 The 'mResult.mParticleEffect' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1135, 1137. apps/wizard/unshield/unshieldworker.cpp 475 warn V728 An excessive check can be simplified. The '(A && B) || (!A && !B)' expression is equivalent to the 'bool(A) == bool(B)' expression. apps/wizard/installationpage.cpp 163 warn V735 Possibly an incorrect HTML. The "</p" closing tag was encountered, while the "</span" tag was expected. components/fontloader/fontloader.cpp 427 err V547 Expression 'i == 1' is always true. components/nifosg/nifloader.cpp 282 warn V519 The 'created' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 278, 282. components/esm/loadregn.cpp 119 err V586 The 'clear' function is called twice for deallocation of the same resource. Check lines: 112, 119. components/esm/cellref.cpp 178 warn V581 The conditional expressions of the 'if' statements situated alongside each other are identical. Check lines: 175, 178. components/esmterrain/storage.cpp 235 warn V560 A part of conditional expression is always true: colStart == 0. components/esmterrain/storage.cpp 237 warn V560 A part of conditional expression is always true: rowStart == 0.
2018-04-09 18:55:16 +03:00
if (rank < 0)
2022-08-12 18:42:12 +02:00
return {};
return faction->mRanks[rank];
}
int InterpreterContext::getPCBounty() const
{
MWBase::World* world = MWBase::Environment::get().getWorld();
MWWorld::Ptr player = world->getPlayerPtr();
return player.getClass().getNpcStats(player).getBounty();
}
std::string_view InterpreterContext::getCurrentCellName() const
{
return MWBase::Environment::get().getWorld()->getCellName();
}
2021-06-23 23:13:59 +02:00
void InterpreterContext::executeActivation(const MWWorld::Ptr& ptr, const MWWorld::Ptr& actor)
{
// MWScripted activations don't go through Lua because 1-frame delay can brake mwscripts.
#if 0
MWBase::Environment::get().getLuaManager()->objectActivated(ptr, actor);
// TODO: Enable this branch after implementing one of the options:
// 1) Pause this mwscript (or maybe all mwscripts) for one frame and continue from the same
// command when the activation is processed by Lua script.
// 2) Force Lua scripts to handle a zero-length extra frame right now, so when control
// returns to the mwscript, the activation is already processed.
#else
std::unique_ptr<MWWorld::Action> action = (ptr.getClass().activate(ptr, actor));
action->execute(actor);
if (action->getTarget() != MWWorld::Ptr() && action->getTarget() != ptr)
{
updatePtr(ptr, action->getTarget());
}
#endif
}
int InterpreterContext::getMemberShort(ESM::RefId id, std::string_view name, bool global) const
{
const Locals& locals = getMemberLocals(global, id);
return locals.mShorts[findLocalVariableIndex(id, name, 's')];
}
int InterpreterContext::getMemberLong(ESM::RefId id, std::string_view name, bool global) const
{
const Locals& locals = getMemberLocals(global, id);
return locals.mLongs[findLocalVariableIndex(id, name, 'l')];
}
float InterpreterContext::getMemberFloat(ESM::RefId id, std::string_view name, bool global) const
{
const Locals& locals = getMemberLocals(global, id);
return locals.mFloats[findLocalVariableIndex(id, name, 'f')];
}
void InterpreterContext::setMemberShort(ESM::RefId id, std::string_view name, int value, bool global)
{
Locals& locals = getMemberLocals(global, id);
locals.mShorts[findLocalVariableIndex(id, name, 's')] = value;
}
void InterpreterContext::setMemberLong(ESM::RefId id, std::string_view name, int value, bool global)
{
Locals& locals = getMemberLocals(global, id);
locals.mLongs[findLocalVariableIndex(id, name, 'l')] = value;
}
void InterpreterContext::setMemberFloat(ESM::RefId id, std::string_view name, float value, bool global)
{
Locals& locals = getMemberLocals(global, id);
locals.mFloats[findLocalVariableIndex(id, name, 'f')] = value;
}
2021-02-14 16:25:38 +01:00
MWWorld::Ptr InterpreterContext::getReference(bool required) const
{
2022-08-12 18:42:12 +02:00
return getReferenceImp({}, true, required);
}
void InterpreterContext::updatePtr(const MWWorld::Ptr& base, const MWWorld::Ptr& updated)
{
if (!mReference.isEmpty() && base == mReference)
{
mReference = updated;
if (mLocals == &base.getRefData().getLocals())
mLocals = &mReference.getRefData().getLocals();
}
}
2010-07-02 18:08:00 +02:00
}