|
|
|
#include "draganddrop.hpp"
|
|
|
|
|
|
|
|
#include <MyGUI_Gui.h>
|
|
|
|
#include <MyGUI_ControllerManager.h>
|
|
|
|
|
|
|
|
#include "../mwbase/windowmanager.hpp"
|
|
|
|
#include "../mwbase/environment.hpp"
|
|
|
|
|
|
|
|
#include "../mwworld/class.hpp"
|
|
|
|
|
|
|
|
#include "sortfilteritemmodel.hpp"
|
|
|
|
#include "inventorywindow.hpp"
|
|
|
|
#include "itemwidget.hpp"
|
|
|
|
#include "itemview.hpp"
|
|
|
|
#include "controllers.hpp"
|
|
|
|
|
|
|
|
namespace MWGui
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
|
|
DragAndDrop::DragAndDrop()
|
|
|
|
: mIsOnDragAndDrop(false)
|
|
|
|
, mDraggedWidget(NULL)
|
|
|
|
, mSourceModel(NULL)
|
|
|
|
, mSourceView(NULL)
|
|
|
|
, mSourceSortModel(NULL)
|
|
|
|
, mDraggedCount(0)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void DragAndDrop::startDrag (int index, SortFilterItemModel* sortModel, ItemModel* sourceModel, ItemView* sourceView, int count)
|
|
|
|
{
|
|
|
|
mItem = sourceModel->getItem(index);
|
|
|
|
mDraggedCount = count;
|
|
|
|
mSourceModel = sourceModel;
|
|
|
|
mSourceView = sourceView;
|
|
|
|
mSourceSortModel = sortModel;
|
|
|
|
|
|
|
|
// If picking up an item that isn't from the player's inventory, the item gets added to player inventory backend
|
|
|
|
// immediately, even though it's still floating beneath the mouse cursor. A bit counterintuitive,
|
|
|
|
// but this is how it works in vanilla, and not doing so would break quests (BM_beasts for instance).
|
|
|
|
ItemModel* playerModel = MWBase::Environment::get().getWindowManager()->getInventoryWindow()->getModel();
|
|
|
|
if (mSourceModel != playerModel)
|
|
|
|
{
|
|
|
|
MWWorld::Ptr item = mSourceModel->moveItem(mItem, mDraggedCount, playerModel);
|
|
|
|
|
|
|
|
playerModel->update();
|
|
|
|
|
|
|
|
ItemModel::ModelIndex newIndex = -1;
|
|
|
|
for (unsigned int i=0; i<playerModel->getItemCount(); ++i)
|
|
|
|
{
|
|
|
|
if (playerModel->getItem(i).mBase == item)
|
|
|
|
{
|
|
|
|
newIndex = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mItem = playerModel->getItem(newIndex);
|
|
|
|
mSourceModel = playerModel;
|
|
|
|
|
|
|
|
SortFilterItemModel* playerFilterModel = MWBase::Environment::get().getWindowManager()->getInventoryWindow()->getSortFilterModel();
|
|
|
|
mSourceSortModel = playerFilterModel;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string sound = mItem.mBase.getClass().getUpSoundId(mItem.mBase);
|
|
|
|
MWBase::Environment::get().getWindowManager()->playSound (sound);
|
|
|
|
|
|
|
|
if (mSourceSortModel)
|
|
|
|
{
|
|
|
|
mSourceSortModel->clearDragItems();
|
|
|
|
mSourceSortModel->addDragItem(mItem.mBase, count);
|
|
|
|
}
|
|
|
|
|
|
|
|
ItemWidget* baseWidget = MyGUI::Gui::getInstance().createWidget<ItemWidget>("MW_ItemIcon", 0, 0, 42, 42, MyGUI::Align::Default, "DragAndDrop");
|
|
|
|
|
|
|
|
Controllers::ControllerFollowMouse* controller =
|
|
|
|
MyGUI::ControllerManager::getInstance().createItem(Controllers::ControllerFollowMouse::getClassTypeName())
|
|
|
|
->castType<Controllers::ControllerFollowMouse>();
|
|
|
|
MyGUI::ControllerManager::getInstance().addItem(baseWidget, controller);
|
|
|
|
|
|
|
|
mDraggedWidget = baseWidget;
|
|
|
|
baseWidget->setItem(mItem.mBase);
|
|
|
|
baseWidget->setNeedMouseFocus(false);
|
|
|
|
baseWidget->setCount(count);
|
|
|
|
|
|
|
|
sourceView->update();
|
|
|
|
|
|
|
|
MWBase::Environment::get().getWindowManager()->setDragDrop(true);
|
|
|
|
|
|
|
|
mIsOnDragAndDrop = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void DragAndDrop::drop(ItemModel *targetModel, ItemView *targetView)
|
|
|
|
{
|
|
|
|
std::string sound = mItem.mBase.getClass().getDownSoundId(mItem.mBase);
|
|
|
|
MWBase::Environment::get().getWindowManager()->playSound(sound);
|
|
|
|
|
|
|
|
// We can't drop a conjured item to the ground; the target container should always be the source container
|
|
|
|
if (mItem.mFlags & ItemStack::Flag_Bound && targetModel != mSourceModel)
|
|
|
|
{
|
|
|
|
MWBase::Environment::get().getWindowManager()->messageBox("#{sBarterDialog12}");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If item is dropped where it was taken from, we don't need to do anything -
|
|
|
|
// otherwise, do the transfer
|
|
|
|
if (targetModel != mSourceModel)
|
|
|
|
{
|
|
|
|
mSourceModel->moveItem(mItem, mDraggedCount, targetModel);
|
|
|
|
}
|
|
|
|
|
|
|
|
mSourceModel->update();
|
|
|
|
|
|
|
|
finish();
|
|
|
|
if (targetView)
|
|
|
|
targetView->update();
|
|
|
|
|
|
|
|
MWBase::Environment::get().getWindowManager()->getInventoryWindow()->updateItemView();
|
|
|
|
|
|
|
|
// We need to update the view since an other item could be auto-equipped.
|
|
|
|
mSourceView->update();
|
|
|
|
}
|
|
|
|
|
|
|
|
void DragAndDrop::onFrame()
|
|
|
|
{
|
|
|
|
if (mIsOnDragAndDrop && mItem.mBase.getRefData().getCount() == 0)
|
|
|
|
finish();
|
|
|
|
}
|
|
|
|
|
[General] Rework container sync to prevent item duping
A main priority in TES3MP development is to avoid making major changes to OpenMW code, so as to avoid merge conflicts in the future. Whenever avoiding potential conflicts seems especially difficult for the proper implementation of a particular multiplayer feature, that multiplayer feature is often put off until later or partially implemented with the intent of being revisited in the future.
Container sync is the perfect example. Previously, the OpenMW code for container actions was kept exactly as it was, with clients unilaterally accepting their own container changes as per singleplayer-specific code, with only the addition that clients sent container packets every time they made a change in a container, packets which were then forwarded unquestioningly by the server to other players. This meant that two players clicking on the same item in a container at the same time both managed to take it, thus duplicating the item.
Immediately after the packets were already forwarded, server scripts were able to check for incorrect changes, such as the removal of more items than should have existed in a container, but they had to send their own packets that attempted to fix what had already been accepted on the initial client and then forwarded to all clients, which was quite onerous in some scenarios, such as when a player on a slow connection immediately dropped items in the world after taking them from a container (which is why the default TES3MP serverside scripts made no attempt at sending corrective packets at all, preferring to expect the matter to be solved in a later C++ implementation).
This commit fixes item duping in containers by preventing container actions from initially running on clients and by ending the automatic forwarding of container packets by the server. Instead, clients now send container packets that act as requests for container actions, and serverside scripts have to forward these requests themselves. In other words, without a matching Container event in the server's Lua scripts, players are completely unable to affect containers for themselves or for others.
To forward a received Container packet, the following line must be used in a Container event in the Lua scripts:
tes3mp.SendContainer(true, true)
When an invalid action count is used in a container request, the serverside scripts can amend it using the following new function:
tes3mp.SetReceivedContainerItemActionCount(objectIndex, itemIndex, actionCount)
Thus, the serverside scripts are able to allow only container actions that are correct based on their own recorded contents for that container.
The OpenMW code allowing unilateral container actions in mwgui/container.cpp is now prevented from executing. When a player's container request is returned to them, code in mwmp/WorldEvent.cpp simulates those container actions instead.
7 years ago
|
|
|
/*
|
|
|
|
Start of tes3mp change (minor)
|
|
|
|
|
|
|
|
Add a deleteDragItems argument that allows the deletion of the
|
|
|
|
items in the drag as oppposed to the regular behavior of returning
|
|
|
|
them to their source model
|
|
|
|
|
|
|
|
This is required to reduce unpredictable behavior for drags approved
|
|
|
|
or rejected by the server
|
|
|
|
*/
|
|
|
|
void DragAndDrop::finish(bool deleteDragItems)
|
|
|
|
/*
|
|
|
|
End of tes3mp change (minor)
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
mIsOnDragAndDrop = false;
|
|
|
|
mSourceSortModel->clearDragItems();
|
[General] Rework container sync to prevent item duping
A main priority in TES3MP development is to avoid making major changes to OpenMW code, so as to avoid merge conflicts in the future. Whenever avoiding potential conflicts seems especially difficult for the proper implementation of a particular multiplayer feature, that multiplayer feature is often put off until later or partially implemented with the intent of being revisited in the future.
Container sync is the perfect example. Previously, the OpenMW code for container actions was kept exactly as it was, with clients unilaterally accepting their own container changes as per singleplayer-specific code, with only the addition that clients sent container packets every time they made a change in a container, packets which were then forwarded unquestioningly by the server to other players. This meant that two players clicking on the same item in a container at the same time both managed to take it, thus duplicating the item.
Immediately after the packets were already forwarded, server scripts were able to check for incorrect changes, such as the removal of more items than should have existed in a container, but they had to send their own packets that attempted to fix what had already been accepted on the initial client and then forwarded to all clients, which was quite onerous in some scenarios, such as when a player on a slow connection immediately dropped items in the world after taking them from a container (which is why the default TES3MP serverside scripts made no attempt at sending corrective packets at all, preferring to expect the matter to be solved in a later C++ implementation).
This commit fixes item duping in containers by preventing container actions from initially running on clients and by ending the automatic forwarding of container packets by the server. Instead, clients now send container packets that act as requests for container actions, and serverside scripts have to forward these requests themselves. In other words, without a matching Container event in the server's Lua scripts, players are completely unable to affect containers for themselves or for others.
To forward a received Container packet, the following line must be used in a Container event in the Lua scripts:
tes3mp.SendContainer(true, true)
When an invalid action count is used in a container request, the serverside scripts can amend it using the following new function:
tes3mp.SetReceivedContainerItemActionCount(objectIndex, itemIndex, actionCount)
Thus, the serverside scripts are able to allow only container actions that are correct based on their own recorded contents for that container.
The OpenMW code allowing unilateral container actions in mwgui/container.cpp is now prevented from executing. When a player's container request is returned to them, code in mwmp/WorldEvent.cpp simulates those container actions instead.
7 years ago
|
|
|
|
|
|
|
/*
|
|
|
|
Start of tes3mp addition
|
|
|
|
|
|
|
|
Make it possible to entirely delete the items in the drag
|
|
|
|
*/
|
|
|
|
if (deleteDragItems)
|
|
|
|
mSourceModel->removeItem(mItem, mDraggedCount);
|
|
|
|
/*
|
|
|
|
End of tes3mp addition
|
|
|
|
*/
|
|
|
|
|
|
|
|
// since mSourceView doesn't get updated in drag()
|
|
|
|
MWBase::Environment::get().getWindowManager()->getInventoryWindow()->updateItemView();
|
|
|
|
|
|
|
|
MyGUI::Gui::getInstance().destroyWidget(mDraggedWidget);
|
|
|
|
mDraggedWidget = 0;
|
|
|
|
MWBase::Environment::get().getWindowManager()->setDragDrop(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|