Dead players will now show up at the correct cell and position for living players, making server scripts that allow players to revive each other much more functional.
According to some legal advice I've received, the "TES3MP Team" is too ambiguous of a legal entity, so – with Koncord's agreement – the copyright is now assigned specifically to us, the project's developers.
This avoids the problems that were encountered in Linux and macOS builds regarding this check while also still addressing the scenario where official Windows builds had their credits modified by people unrelated to the project.
Originally, the PlayerSkill packet contained skills, attribute increases and level progress. In 78441c769a, the attribute increases were moved to the PlayerAttribute packet and the level progress was moved to the PlayerLevel packet, but – due to an oversight – attribute increases and level progress were still being applied to the local player only when a PlayerSkill packet was received, based on whatever values were stored from the last PlayerAttribute and PlayerLevel packets.
Previously, when recharging or repairing an item, the client sent a PlayerInventory packet to the server with the old version of the item that was supposed to be removed and then it sent a PlayerInventory packet with the new version of the item that was supposed to be added.
Unfortunately, the current CoreScripts make it so custom items using generated IDs have their records deleted when they are completely removed from the world, however briefly, even if they are added back immediately afterwards. In practice, this meant that – before this commit – recharging or repairing a custom item led to its removal from the player inventory stored on the server, followed by the deletion of its record, followed by its readdition to the inventory (but with the record staying deleted). Logging out and logging back in immediately prevented the player from receiving the item anymore because of its now non-existent record.
Previously, multiple stacks of the same item ID could overwrite data in each other because of how the logic in ContainerStore::add() works. For example, a stack of 5 grand soul gems with no souls would get added to the player, then the attempt to add a grand soul gem with a particular soul would retrieve the previous stack first before setting all of it to that soul, resulting in 6 grand soul gems with that soul.
Previously, unstacking items for a player led to a PlayerInventory packet being sent about the items' removal.
This change makes it so both a packet about their re-addition and their removal are sent instead, cancelling each other out, which is inelegant, but arguably preferable to complicating the sending of PlayerInventory packets again.
Enchanted inventory items continuously recharge their enchantment charges, which getItemPtrFromStore() should account for.
Additionally, prevent framelistener errors caused by PlayerItemUse packets about non-existent items.
This prevents infinite loops in certain client scripts from mods that use while loops to determine that all items of a certain type have been removed from a container, such as in the script BCSwap2Arg from Better_Clothes.
Previously, client mods adding packet-sending scripts to the spawn area made clients send the associated packets as soon as they inputted their character name when joining a server using those mods. This made the clients either get disconnected for not replying to a handshake first, or it made them get kicked for sending object packets that are disallowed for players who are not logged in.
To fix this, LocalPlayer's hasFinishedCharGen() has been replaced with isLoggedIn(), because the former was already returning true when players inputted their names.
Functions that add elements to a vector should not change the action. This fixes the last remaining oddity in Koncord's original implementation of inventory sync.
This makes it possible to send custom records used by players for their equipment before the hardcoded exchange of equipment packets takes place.
Additionally, remove the check for dead players because it has no real use and can potentially cause problems.
Previously, the player's currently selected weapon was being used in ranged attacks as in the original melee-oriented attack sync, which meant that shooting one type of projectile and then equipping another while the old projectile was still in the air turned the old projectile into the new projectile upon impact.
Additionally, avoid running most of the code in MechanicsHelper::assignAttackTarget() for non-hitting melee and ranged attacks.
This is done by including the final attackStrength used for ranged attacks in packets and then applying it in WeaponAnimation::releaseArrow() on other clients.
Projectile hits now send Attack packets with RANGED attacks, and their success or failure is now synchronized.
Strike enchantments no longer require a valid victim to be synchronized.
Additional debug messages have been added for attacks.
Previously, synchronization for strike enchantments was partially broken because it triggered the sending of ITEM_MAGIC attack packets, which are only supposed to be sent when a spell is cast from a magical inventory item.
Whenever an item is added to or removed from the player's ContainerStore, that player sends a PlayerInventory packet with just that addition or removal.
This eliminates all the unnecessary packet spam related to oversized PlayerInventory packets that had existed in one form or another since the initial implementation of inventory sync in 1b259e2d33
Additionally, move booleans from BasePlayer to LocalPlayer when they are only needed on the client, and make the usage of the isReceivingQuickKeys boolean consistent with the new isReceivingInventory boolean by having them both in the processors of their associated packets.
For a long time, whenever a PlayerInventory packet was sent, it contained all the items in the player's inventory, because that's how Koncord originally implemented it and I always had too many other priorities to go back and rework it.
From now on, clients only send PlayerInventory packet with the one item added or removed, with the single exception being trading with merchants, where the entire inventory is still sent for the time being.
When LocalActors briefly become DedicatedActors as the result of a server script, the DedicatedActors are immediately uninitialized to avoid bugs like them jumping in place or rotating slightly.
Additionally, the playing of animations and sounds received in packets for DedicatedActors is no longer done during their next update, but is instead done instantly when the packets are received.
The variable equipmentItem is identical to currentItem, so it should not have been added in commit 58a6a8c3bc
Addditionally, use a more descriptive variable name than "a" for item Ptrs.
Players can no longer unilaterally use items on themselves in their inventory. When they try to use an item, they send a PlayerItemUse packet to the server with the item's details. A serverside script can then check the item and either send the packet back to make the item use go through or drop it.
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.
This makes it possible to "reload" the Ptrs in active cells when changes happen to the ESM record that they are based on. In practice, the old Ptrs are deleted, their RefNums and MpNums are blanked out, and new Ptrs are created that use the same RefNum and MpNum as before.
The above has required me to also add a method called setRefNum() to CellRef to allow setting a RefNum on the fly.
There may be a more elegant implementation available for updatePtrsWithRefIds(), but it requires additional research.
Previously, attempts to reuse the same reference for multiple creature disguises led to movement animation issues, as well as a dynamic_cast error in Creature::getInventoryStore() that made a DedicatedPlayer vanish completely when they first lost their creature disguise, then disguised themselves as a creature that could not hold weapons and then disguised themselves as a creature that could hold weapons.
The usage of const_cast has been replaced with usage of MWWorld::getModifiableStore() and ESMStore::overrideRecord()
Methods whose names started with "update" now start with "override", for consistency with ESMStore's overrideRecord()
New methods have been added for "overriding" enchantment, potion and spell records, which actually leads to them being created with their already set refIds if they haven't been created yet, as per the description of ESMStore::overrideRecord(): "Insert a record with set ID, and allow it to override a pre-existing static record."
Usage of RecordHelper methods has been updated in DedicatedPlayer.
Actors who are on the ground have their inertial force ignored, so they are now made to not be regarded as being on the ground in World::setInertialForce()
I originally added rotation animation sync as part of commit 068a45be87. Unfortunately, it meant the PlayerPosition packets were now twice as large as they had been before, which was less than ideal for such a frequently sent packet, which is why Koncord switched to a more optimized approach in commits 5f30dfd5db and d67db1a9bd.
Recently, there have since been some rotation animation problems in OpenMW, which have broken the way Koncord's approach looks. My original approach still looks somewhat okay, so I'm switching back to it until we can figure out how to reuse it under the current circumstances.
Although weather sync was added by Koncord to the rewrite in fd721143e2 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.
This should clarify the real meaning of the packet and its associated event.
The event itself has been renamed from OnPlayerKillCount to OnWorldKillCount.
This new crash catcher is preventing TES3MP from building on GNU/Linux
`components/crashcatcher/crashcatcher.cpp:23:28: fatal error: SDL_messagebox.h: No such file or directory`
Disable it until the developers isolate the issue and patch it
The ActorPacket-sending functions now have sendToOtherVisitors and skipAttachedPlayer arguments, except for the ones for ActorList and ActorAuthority (because such arguments don't make sense for those).
The last received ActorList can now be copied into the write-only ActorList that can be sent in packets. Changing the pid of the write-only ActorList can now be done separately from clearing its contents.
The server can now make actors activate players and objects, at least in theory. In practice, OpenMW''s AiActivate package needs to be worked so it allows specific objects as targets instead of just refIds.
There were some errors in the texture modding page about normal maps, so I did a quick change. Please do review if I made some errors, spelling or factual.
Unfortunately, disabling clientside deletion of summons and items that can be picked up requires extra work on actors and inventories respectively, to avoid buggy situations.
Unfortunately, default values set in the C++ code for our script function parameters don't actually seem to work, and they always default to false because they receive a nil value from Lua. As a result, to not break compatibility with previous scripts, I've decided to use a skipAttachedPlayer argument instead so it can default to false while still providing the same benefits that sendToAttachedPlayer provided.
Previously, there was a confusing separation between script functions that had a "broadcast" argument and script functions that had a "toOthers" argument.
Those with broadcast sent the packet to all players on the server when broadcast was true. Those with toOthers sent the packet to all players other than the packet's attached player.
The former was based on the pattern of the original SendMessage() script function. The latter more closely resembled RakNet's own broadcast argument as seen here:
https://github.com/TES3MP/CrabNet/blob/master/include/raknet/RakPeer.h#L219
This commit makes it so all sending functions have a sendToOtherPlayers argument that is false by default and a sendToAttachedPlayer that is true by default. This should simultaneously allow sending to be more intuitive, while not breaking previous existing scripts to a significant degree.
Additionally, this commit also reduces some code repetition for all instances of packet-fetching in script functions.
Add a section, under the provisional name "Baby Steps" to describe a minimal process for editing/contributing. Basically just create an account on GitLab, fork openmw there, then edit the relevant document to create Merge Request
Previously, all crime witnesses stopped being hostile to a respawning player for as long as the player's diedSinceArrestAttempt was true. That meant that, in an area with no guards to arrest the player, crime witnesses did not enage in combat with the player at all ever again until diedSinceArrestAttempt became false.
This commit makes it so the time of the last crime is recorded for each witness, and that is then compared with the time of the LocalPlayer's last death for a one-time crime forgiveness during that player's current life.
This is essentially a gameplay adjustment for "singleplayer with respawns," and will have to be reworked to make sense for every player in multiplayer, though that requires reworking the crime system as a whole and is thus on hold.
Add serverside script functions for determining the killers of both players and actors.
Use unsigned ints for script functions returning an object or actor's refNumIndex or mpNum.
Remove updateDeadState() from LocalPlayer and make its code part of updateStatsDynamic() for simplicity.
A subsequent MR will suggest moving most of this to a separate document for intermediate-level contributors, and replacing it with much simpler instructions for beginners - basically edit directly on GitLab as suggested by Psi29a on the forum here - https://forum.openmw.org/viewtopic.php?f=43&p=56458#p56457
This prevents summon duplication caused by a SummonKey sometimes being deleted immediately after being created, before the server can send back an ObjectSpawn packet spawning a creature that can be attached to the SummonKey.
Prevents compiler warnings such as this:
```
/Users/Will/CLionProjects/OpenMW/apps/openmw/mwgui/windowbase.hpp:65:22: warning: 'onOpen' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
virtual void onOpen();
^
/Users/Will/CLionProjects/OpenMW/apps/openmw/mwgui/windowbase.hpp:38:22: note: overridden virtual function is here
virtual void onOpen() {}
^
```
ActorDeath packets are sent for dead actors before their StatsDynamic packets. They contain the actor's deathReason in a manner similar to that of PlayerDeath packets.
A future commit will replace the deathReason with a variable named killer which will be an mwmp::Target.
added a MWWorld::ContainerStore to hold item copies which are then used to find
real items with findReplacement().
(storing the RefId could be a better solution but would probably leave tooltips broken...)
Make sure only players who are cell authorities can get actors to teleport across cells for them, and display a message box for players who are not cell authorities.
Improves previous commit:
1. Initialise mIgnoreBase boolean member with FALSE.
2. Remove isBaseOnly() function and replace with direct use of Record member.
Adds a boolean setting to the user preferences. This setting is locally saved to all OpenMW-CS check stages. When a verification is done, the setting is updated on setup for each check stage. If set to true, the boolean value is then used to skip the verification process for every base record - minus some special cases where, e.g., counters are to be set first.
Related issue:
- Fixes#4466: Editor: Add option to ignore base records when running verifier (https://gitlab.com/OpenMW/openmw/issues/4466)
Tests:
The changes were successfully tested in OpenMW-CS by creating faulty "Base" and "Modified" records for every record type (if possible) and, then, running the verifier with and without the option respectively.
openmw/apps/openmw/mwworld/worldimp.cpp: In member function ‘virtual bool MWWorld::World::findExteriorPosition(const string&, ESM::Position&)’:
openmw/apps/openmw/mwworld/worldimp.cpp:2650:25: warning: catching polymorphic type ‘class std::invalid_argument’ by value [-Wcatch-value=]
catch (std::invalid_argument)
^~~~~~~~~~~~~~~~
openmw/apps/openmw/mwworld/worldimp.cpp:2654:25: warning: catching polymorphic type ‘class std::out_of_range’ by value [-Wcatch-value=]
catch (std::out_of_range)
^~~~~~~~~~~~
openmw/components/widgets/numericeditbox.cpp: In member function ‘void Gui::NumericEditBox::onEditTextChange(MyGUI::EditBox*)’:
openmw/components/widgets/numericeditbox.cpp:41:21: warning: catching polymorphic type ‘class std::invalid_argument’ by value [-Wcatch-value=]
catch (std::invalid_argument)
^~~~~~~~~~~~~~~~
openmw/components/widgets/numericeditbox.cpp:45:21: warning: catching polymorphic type ‘class std::out_of_range’ by value [-Wcatch-value=]
catch (std::out_of_range)
^~~~~~~~~~~~
Although b4e8560698 made players instantly able to see each other on minimalist servers that did not change their cells from the default, it created problems with the default CoreScripts where players need to be logged in before receipt of a CellStates packet from them is taken into account, with the result being that a player was recorded as having loaded their initial cells on the server's C++ side but not on the Lua side.
It may simply be best to expect servers to set player cells.
Previously, turning off communication with the MasterServer from the server config and then attempting to use SetGameMode() or SetHostname() led to a server crash.
Since the beginnings of TES3MP, equipment packets have only been sent whenever an item has been replaced by an item with a different refId, with changes in an item's charge or count not sending a packet (but being included in the next packet sent as a result of a refId change). The reason for this was ostensibly the fact that every single equipment packet always included the details for all 19 equipment items (as per Koncord's original design decision), which would have led to massive packet spam if such a packet was sent every time you shot an arrow or lost a little bit of your armor's condition.
With minimalist equipment packets, it is now viable to send equipment packets whenever any item changes in some way, by having the equipment packet contain only that one item.
Previously, the index changes were not cleared at the start of their corresponding update functions, which in turn meant that an Attribute/Skill/StatsDynamic/Equipment packet received by a player from the server made that player send back the same packet, as the index changes from it were retained.
Additionally, exchangeFullInfo was not set to false, thus sometimes leading to constant full exchanges of information.
Previously, two players entering the same cell only sent and received their latest changes for dynamic stats, attributes, skills and equipment when they started sharing that cell.
Previously, whenever a single attribute value changed for a player, that player then sent a PlayerAttribute packet with all values for all 8 attributes.
This did not cause anywhere as much packet spam as PlayerSkill used to, but there was no good reason not to fix it as well.
(cherry picked from commit b0965f094a)
Previously, whenever a single skill value changed for a player, that player then sent a PlayerSkill packet with all values for all 27 skills, plus the player's progress towards the next level and the bonuses to each attribute on the next level up as the result of sklll increases thus far.
This commit makes PlayerSkill contain only the values of specific skills, moves the player's progress towards the next level to PlayerLevel packets, and moves the bonuses to each attribute on the next level up to PlayerAttribute packets.
Players now also send a PlayerSkill packet whenever their progress towards a new point in a skill changes. This was previously avoided so as to not have massive packet spam.
(cherry picked from commit ef79a98544)
Previously, an attempt by the server to simultaneously change a player's cell and skills (as you'd expect when a player file is loaded) led to:
1) The server sending the cell packet first and the skill packet afterwards
2) The player receiving the cell packet and sending their own skill packet as part of the client's forced skill update
3) The player receiving the skill packet from the server
4) The server receiving the skill packet from the player
The result was that, if the player then left the server without sending another skill packet, the server's memory retained the skills the player had sent instead of the skills it had sent to the player.
This is the first step in a solution to that situation and similar ones.
(cherry picked from commit cac4684986)
Note: In 0.6.x, this was only a problem if a player's cell was set by the server first and their skills were set next, i.e. this was not a problem in the default CoreScripts because the opposite order used there masked the problem. It was a more significant problem in 0.7 because all packets were queued for a player and sent in a specific hardcoded order.
Previously, after finishing the TES3MP chargen once, mCreationStage was set to 4 in OpenMW, which in turn made it impossible to go through only specific chargen menus again as the result of the relevant TES3MP script function (tes3mp.SetCharGenStage(pid, startStage, endStage) in 0.6.3, player:setCharGenStages(startStage, endStage) in 0.7). In other words, trying to allow a player to just choose their class again made it so the player started at that menu and went through all the other subsequent menus as well, i.e. the player went through the class, birthsign and review menus.
Previously, charGenStage.end was doing double duty as both the variable indicating the number of CharGen stages and – when set to 0 – the variable indicating that CharGen was over. The latter role is now filled by a new boolean.
(cherry picked from commit 926106cf8c)
Previously, initial cell states were sent in LocalPlayer::processCharGen() and were ignored by the server because the player was not yet regarded as loaded. The result was that existing players logging in could not see each other until they went through at least one cell change.
(cherry picked from commit b4e8560698)
# Conflicts:
# apps/openmw/mwmp/LocalPlayer.cpp
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.
This avoids the following error when receiving repeated PlayerBaseInfo packets: "Error in frame: Invalid slot, make sure you are not calling RefData::setCount for a container object"
Additionally, only re-equip items as the result of a PlayerBaseInfo packet if resetStats is true (because of its side effect of auto-equipping items for the player).
Unfortunately, the handshake attempt limit implemented in 4ebfcc4a21 for 0.7 and then ported over to 0.6 in a3a341fee6 does not appear to work properly, which is why gathering more information on it is important.
Additionally, delete DedicatedPlayers who disconnect.
Previously, all disconnected DedicatedPlayers were still kept in memory, but never used again. There was code that suggested they were meant to be reused upon reconnecting, but that reuse had never actually been implemented, and would probably not be that useful anyway.
Additionally, print player guids using their string representations for consistency.
The creation and updating of DedicatedPlayer references remains very inelegant, but this commit is the first step towards fixing that.
To fix warnings:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/bits/shared_ptr_base.h:588:8: warning: delete called on non-final 'NifOsg::ControllerFunction' that has virtual functions but non-virtual destructor
[-Wdelete-non-virtual-dtor]
delete __p;
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<NifOsg::ControllerFunction *>' requested here
: __shared_count(__p)
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<NifOsg::ControllerFunction *>' requested here
: _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<NifOsg::ControllerFunction,
__gnu_cxx::_S_atomic>::__shared_ptr<NifOsg::ControllerFunction, void>' requested here
shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
^
/home/elsid/dev/openmw/components/nifosg/nifloader.cpp:242:39: note: in instantiation of function template specialization 'std::shared_ptr<NifOsg::ControllerFunction>::shared_ptr<NifOsg::ControllerFunction, void>' requested here
callback->setFunction(std::shared_ptr<NifOsg::ControllerFunction>(new NifOsg::ControllerFunction(key)));
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/bits/unique_ptr.h:78:2: warning: delete called on non-final 'MWGui::ResponseCallback' that has virtual functions but non-virtual destructor
[-Wdelete-non-virtual-dtor]
delete __ptr;
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/bits/unique_ptr.h:268:4: note: in instantiation of member function 'std::default_delete<MWGui::ResponseCallback>::operator()' requested here
get_deleter()(__ptr);
^
/home/elsid/dev/openmw/apps/openmw/mwgui/dialogue.cpp:58:23: note: in instantiation of member function 'std::unique_ptr<MWGui::ResponseCallback, std::default_delete<MWGui::ResponseCallback> >::~unique_ptr' requested here
PersuasionDialog::PersuasionDialog(ResponseCallback* callback)
^
Previously, a Container packet with a REQUEST action always made the client respond with the contents of all the containers in that cell.
The previous behavior now only happens for requests that have no WorldObjects attached, while requests that have WorldObjects attached get a reply with the contents of those specific containers.
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.
Previously, throwing weapon sync was completely broken for players, as the count for their equipped throwing weapons was never set and – as a result – defaulted to a count of 1 on other clients. As a result, any time a player threw a dart, they would then appear as having switched to hand-to-hand for other players.
Moreover, the count of equipped items was mistakenly based on the total count of items with that refId in the inventory. As a result, if – for example – I equipped 1 Daedric Longsword and had 4 others in my inventory, my DedicatedPlayer on other clients would equip a Daedric Longsword with a count of 5. If I was overencumbered by having that many Daedric Longswords on me and then dropped 4 of them, allowing myself to move again, my DedicatedPlayer would still walk around with 5 Daedric Longswords and lack animations due to still being overencumbered on the other clients.
These problems were less prevalent for actors, but their equipment updating code has also been changed to match that of players.
Certain servers do not want the players to have debug information about the locations and actions of other players, so a client's log level can now be enforced by the server via the GameSettings packet.
* http to https for supported urls
* http to https
* http to https
* http to https
* http to https
* http to https
* http to https
* http to https
* http tp https
* http to https
* http to https
* http to https
* http to https
* http to https
* http to https
* http to https
* http to https
* some url fixes
* http to https
This allows the distant land to actually be seen when the user enables it. The
values used are replicated from MGE XE's default settings and should probably
be exposed somewhere.
When multiple quicksaves occurred in quick succession, the numeric order
of the saves could not be guaranteed. To prevent players from getting
confused as to why their saves appear out of order, don't number them.
This allows the OnPCDrop variable to get set correctly even when object placements have to go through the server first in order to gain a unique multiplayer index (mpNum).
Among other things, this makes it possible to roll marijuana joints in the popular mod "Tribunal Code Patch".
With more than 1 quicksave slot, slots will be created each time you
quicksave until the maximum number (configured in settings) of
quicksaves has been reached. After that, the oldest quicksave slot will
be replaced each time you quicksave. Saves are numbered sequentially,
unless the maximum number of slots is 1, in which case it is not numbered.
This reverts commit 45993d3da2, reversing
changes made to 3d347730dc.
That commit made players have to wait around 1.5 seconds after each jump before doing a new one.
It will be reinstated once its accompanying OpenMW issue at https://bugs.openmw.org/issues/4250 is fixed.
Previously, reusing the console's object selection code made it so using the same Ptr twice in a row was akin to clicking on the same object twice in the console window, i.e. the object was deselected the second time around. Additionally, that same code was setting key focus to the hidden console window, preventing players from moving until they activated another window (such as their inventory or chat window).
There's no way SetAttributeModifier() was going to make sense if, say, a player had drunk 3 different potions fortifying the same attribute and was wearing equipment fortifying it as well. How would one change the sum modifier of those while accounting for each specific effect's duration and magnitude?
The only workable solution is to allow the server to clear the modifier.
By definition this is not 'Mutable state of a cell' and does not belong in CellStore.
This change should improve startup times (graph is now loaded on demand) and edits to 'pathgrid.hpp' no longer cause the entirety of OpenMW to be rebuilt.
For one, because their RepeatClick handler breaks the keyboard function, and because its redundant anyway (just press Up/Down arrow with the edit box focused to do the same thing)
* Create LICENSE
Let's add the license file so that GitHub officially registers it and displays it next to the project.
* move license files
* update licenses in cmakelists.txt
* fix link in README
Found on the bug http://bugs.openmw.org/issues/4165.
In original Morrowind, new clothing of the same value wouldn't replace old clothing. Tested with common and expensive clothing by selling to merchants and using the AddItem console command in original Morrowind.
In OpenMW, before this change, new clothing of the same value would replace old clothing, tested with the same methods used above.
Fixes a crash when closing the game window during the 'plugin mismatch' dialog. Modal windows have to be hidden before they are deleted to prevent a dangling pointer in WindowManager.
It's no longer possible to cycle to widgets that aren't part of the current modal window.
The window manager will remember the focused widget of a modal window on a limited basis (it'll be discarded when a different modal window opens).
(Shift)Tab cycles, arrow keys move to the next button in that direction, Enter/Space accepts.
Note: Unless MyGUI is hacked to bits, clicking on an empty space will annoyingly reset the key focus. Not sure how to deal with that yet.
The visual highlight for selected buttons requires MyGUI commit 632d007429d0bf0c7d7f6c5db4a08353a63dd839 or later to appear (to be released in 3.2.3).
After MyGUI commit cfdaf5f , the 'Client' area will be used for every type of widget, whereas previously it would only be used for some widgets like 'Window'. Use 'Window' widget where the client was always used.
This fixes a wrong margin when built with cfdaf5f or later.
Not sure what to do with all your free time? Pick out a task from here:
Not sure what to do with all your free time? Pick out a task from here:
http://bugs.openmw.org/
https://gitlab.com/OpenMW/openmw/issues
Currently, we are focused on completing the MW game experience and general polishing. Features out of this scope may be approved in some cases, but you should probably start a discussion first.
Currently, we are focused on completing the MW game experience and general polishing. Features out of this scope may be approved in some cases, but you should probably start a discussion first.
Note:
Note:
- Tasks set to 'openmw-future' are usually out of the current scope of the project and can't be started yet.
* Tasks set to 'openmw-future' are usually out of the current scope of the project and can't be started yet.
- Bugs that are not 'Confirmed' should be confirmed first.
* Bugs that are not 'Confirmed' should be confirmed first.
- Larger Features should have a discussion before you start implementing.
* Often, it's best to start a discussion about possible solutions before you jump into coding, especially for larger features.
- In many cases, it's best to have a discussion about possible solutions before you jump into coding.
Aside from coding, you can also help by triaging the issues list. Check for bugs that are 'Unconfirmed' and try to confirm them on your end, working out any details that may be necessary. Check for bugs that do not conform to [Bug reporting guidelines](https://wiki.openmw.org/index.php?title=Bug_Reporting_Guidelines) and improve them to do so!
Aside from coding, you can also help by triaging the issues list. Check for bugs that are 'Unconfirmed' and try to confirm them on your end, working out any details that may be necessary. Check for bugs that do not conform to [Bug reporting guidelines](https://wiki.openmw.org/index.php?title=Bug_Reporting_Guidelines) and improve them to do so!
@ -20,19 +19,21 @@ There are various [Tools](https://wiki.openmw.org/index.php?title=Tools) to faci
Pull Request Guidelines
Pull Request Guidelines
=======================
=======================
Thought of a change? Great! To facilitate the review process, your pull request description should include the following (if applicable):
To facilitate the review process, your pull request description should include the following, if applicable:
* A link back to the bug report or forum discussion that prompted the change
* A link back to the bug report or forum discussion that prompted the change. Note: when linking bugs, use the syntax ```[Bug #xyz](https://bugs.openmw.org/issues/#xyz)``` to create a clickable link. Writing only 'Bug #xyz' will unfortunately create a link to the Github pull request with that number instead.
* Summary of the changes made
* Summary of the changes made
* Reasoning / motivation behind the change
* Reasoning / motivation behind the change
* What testing you have carried out to verify the change
* What testing you have carried out to verify the change
Furthermore, we advise to:
Furthermore, we advise to:
* Separate your work into multiple pull requests whenever possible. As a rule of thumb, each feature and each bugfix should go into a separate PR, unless they are closely related or dependent upon each other. Small pull requests are easier to review, and are less likely to require further changes before we can merge them. A "mega" pull request with lots of unrelated commits in it is likely to get held up in review for a long time.
* Avoid stuffing unrelated commits into one pull request. As a rule of thumb, each feature and each bugfix should go into a separate PR, unless they are closely related or dependent upon each other. Small pull requests are easier to review, and are less likely to require further changes before we can merge them. A "mega" pull request with lots of unrelated commits in it is likely to get held up in review for a long time.
* Feel free to submit incomplete pull requests. Even if the work can not be merged yet, pull requests are a great place to collect early feedback. Just make sure to mark it as *[Incomplete]* or *[Do not merge yet]* in the title.
* Feel free to submit incomplete pull requests. Even if the work can not be merged yet, pull requests are a great place to collect early feedback. Just make sure to mark it as *[Incomplete]* or *[Do not merge yet]* in the title.
* If you plan on contributing often, please read the [Developer Reference](https://wiki.openmw.org/index.php?title=Developer_Reference) on our wiki, especially the [Policies and Standards](https://wiki.openmw.org/index.php?title=Policies_and_Standards).
* If you plan on contributing often, please read the [Developer Reference](https://wiki.openmw.org/index.php?title=Developer_Reference) on our wiki, especially the [Policies and Standards](https://wiki.openmw.org/index.php?title=Policies_and_Standards).
* Make sure each of your changes has a clear objective. Unnecessary changes may lead to merge conflicts, clutter the commit history and slow down review. Code formatting 'fixes' should be avoided, unless you were already changing that particular line anyway.
* Make sure each of your changes has a clear objective. Unnecessary changes may lead to merge conflicts, clutter the commit history and slow down review. Code formatting 'fixes' should be avoided, unless you were already changing that particular line anyway.
* Reference the bug / feature ticket(s) in your commit message (e.g. 'Bug #123') to make it easier to keep track of what we changed for what reason. Our bugtracker will show those commits next to the ticket. If your commit message includes 'Fixes #123', that bug/feature will automatically be set to 'Closed' when your commit is merged.
* When pulling changes from master, prefer rebase over merge. Consider using a merge if there are conflicts or for long-running PRs.
Guidelines for original engine "fixes"
Guidelines for original engine "fixes"
=================================
=================================
@ -46,7 +47,7 @@ Unfortunately, the definition of what is a "bug" is not so clear. Consider that
* Many people will actually <i>like</i> these "bugs" because that is what they remember the game for.
* Many people will actually <i>like</i> these "bugs" because that is what they remember the game for.
* Exploits may be part of the fun of an open-world game - they reward knowledge with power. There are too many of them to plug them all, anyway.
* Exploits may be part of the fun of an open-world game - they reward knowledge with power. There are too many of them to plug them all, anyway.
OpenMW, in its default configuration, is meant to be a faithful reimplementation of Morrowind, minus things like crash bugs, stability issues and design errors. However, we try to avoid touching anything that affects the core gameplay, the balancing of the game or introduces incompatibilities with existing mod content.
OpenMW, in its default configuration, is meant to be a faithful reimplementation of Morrowind, minus things like crash bugs, stability issues and severe design errors. However, we try to avoid touching anything that affects the core gameplay, the balancing of the game or introduces incompatibilities with existing mod content.
That said, we may sometimes evaluate such issues on an individual basis. Common exceptions to the above would be:
That said, we may sometimes evaluate such issues on an individual basis. Common exceptions to the above would be:
@ -61,10 +62,54 @@ We get it, you have waited so long for feature XYZ to be available in Morrowind
Unfortunately, since maintaining features comes at a cost and our resources are limited, we have to be a little selective in what features we allow into the main repository. Generally:
Unfortunately, since maintaining features comes at a cost and our resources are limited, we have to be a little selective in what features we allow into the main repository. Generally:
- Features should be as generic and non-redundant as possible.
* Features should be as generic and non-redundant as possible.
- Any feature that is also possible with modding should be done as a mod instead.
* Any feature that is also possible with modding should be done as a mod instead.
- In the future, OpenMW plans to expand the scope of what is possible with modding, e.g. by moving certain game logic into editable scripts.
* In the future, OpenMW plans to expand the scope of what is possible with modding, e.g. by moving certain game logic into editable scripts.
- Currently, modders can edit OpenMW's GUI skins and layout XML files, although there are still a few missing hooks (e.g. scripting support) in order to make this into a powerful way of modding.
* Currently, modders can edit OpenMW's GUI skins and layout XML files, although there are still a few missing hooks (e.g. scripting support) in order to make this into a powerful way of modding.
- If a feature introduces new game UI strings, that reduces its chance of being accepted because we do not currently have any way of localizing these to the user's Morrowind installation language.
* If a feature introduces new game UI strings, that reduces its chance of being accepted because we do not currently have any way of localizing these to the user's Morrowind installation language.
If you are in doubt of your feature being within our scope, it is probably best to start a forum discussion first. See the [settings documentation](https://openmw.readthedocs.io/en/stable/reference/modding/settings/index.html) and [Features list](https://wiki.openmw.org/index.php?title=Features) for some examples of features that were deemed acceptable.
If you are in doubt of your feature being within our scope, it is probably best to start a forum discussion first. See the [settings documentation](https://openmw.readthedocs.io/en/stable/reference/modding/settings/index.html) and [Features list](https://wiki.openmw.org/index.php?title=Features) for some examples of features that were deemed acceptable.
Reviewing pull requests
=======================
We welcome any help in reviewing open PRs. You don't need to be a developer to comment on new features. We also encourage ["junior" developers to review senior's work](https://pagefault.blog/2018/04/08/why-junior-devs-should-review-seniors-commits/).
This review process is divided into two sections because complaining about code or style issues hardly makes sense until the functionality of the PR is deemed OK. Anyone can help with the Functionality Review while most parts of the Code Review require you to have programming experience.
In addition to the checklist below, make sure to check that the Pull Request Guidelines (first half of this document) were followed.
First review
============
1. Ask for missing information or clarifications. Compare against the project's design goals and roadmap.
2. Check if the automated tests are passing. If they are not, make the PR author aware of the issue and potentially link to the error line on Travis CI or Appveyor. If the error appears unrelated to the PR and/or the master branch is failing with the same error, our CI has broken and needs to be fixed independently of any open PRs. Raise this issue on the forums, bug tracker or with the relevant maintainer. The PR can be merged in this case as long as you've built it yourself to make sure it does build.
3. Make sure that the new code has been tested thoroughly, either by asking the author or, preferably, testing yourself. In a complex project like OpenMW, it is easy to make mistakes, typos, etc. Therefore, prefer testing all code changes, no matter how trivial they look. When you have tested a PR that no one has tested so far, post a comment letting us know.
4. On long running PRs, request the author to update its description with the current state or a checklist of things left to do.
Code Review
===========
1. Carefully review each line for issues the author may not have thought of, paying special attention to 'special' cases. Often, people build their code with a particular mindset and forget about other configurations or unexpected interactions.
2. If any changes are workarounds for an issue in an upstream library, make sure the issue was reported upstream so we can eventually drop the workaround when the issue is fixed and the new version of that library is a build dependency.
3. Make sure PRs do not turn into arguments about hardly related issues. If the PR author disagrees with an established part of the project (e.g. supported build environments), they should open a forum discussion or bug report and in the meantime adjust the PR to adhere to the established way, rather than leaving the PR hanging on a dispute.
4. Check if the code matches our style guidelines.
5. Check to make sure the commit history is clean. Squashing should be considered if the review process has made the commit history particularly long. Commits that don't build should be avoided because they are a nuisance for ```git bisect```.
Merging
=======
To be able to merge PRs, commit priviledges are required. If you do not have the priviledges, just ping someone that does have them with a short comment like "Looks good to me @user".
The person to merge the PR may either use github's Merge button or if using the command line, use the ```--no-ff``` flag (so a merge commit is created, just like with Github's merge button) and include the pull request number in the commit description.
Dealing with regressions
========================
The master branch should always be in a working state that is not worse than the previous release in any way. If a regression is found, the first and foremost priority should be to get the regression fixed quickly, either by reverting the change that caused it or finding a better solution. Please avoid leaving the project in the 'broken' state for an extensive period of time while proper solutions are found. If the solution takes more than a day or so then it is usually better to revert the offending change first and reapply it later when fixed.
Other resources
===============
[GitHub blog - how to write the perfect pull request](https://blog.github.com/2015-01-21-how-to-write-the-perfect-pull-request/)
Copyright (c) 2016-2019, Stanislav Zhukov & David Cernat
TES3MP is a project aiming to add multiplayer functionality to [OpenMW](https://github.com/OpenMW/openmw), a free and open source recreation of the popular Bethesda Softworks game "The Elder Scrolls III: Morrowind".
TES3MP is a project adding multiplayer functionality to [OpenMW](https://github.com/OpenMW/openmw), an open-source game engine that supports playing "The Elder Scrolls III: Morrowind" by Bethesda Softworks.
* License: GPLv3 (see docs/license/GPL3.txt for more information)
* TES3MP version: 0.7.0-alpha
* OpenMW version: 0.44.0
* License: GPLv3 (see [LICENSE](https://github.com/TES3MP/openmw-tes3mp/blob/master/LICENSE) for more information)
Font Licenses:
Font Licenses:
* DejaVuLGCSansMono.ttf: custom (see docs/license/DejaVu Font License.txt for more information)
* DejaVuLGCSansMono.ttf: custom (see [files/mygui/DejaVu Font License.txt](https://github.com/TES3MP/openmw-tes3mp/blob/master/files/mygui/DejaVu%20Font%20License.txt) for more information)
TES3MP is now playable in most respects. Player and NPC movement, animations, combat and spell casting are properly synchronized with small exceptions, as is picking up and dropping items in the world, using doors and levers, and adding and removing items from containers. Journal entries, faction stats and dialogue topics are also synchronized, allowing the majority of quests to work fine.
As of version 0.7.0, TES3MP is fully playable, providing very extensive player, NPC, world and quest synchronization, as well as state saving and loading, all of which are highly customizable via [serverside Lua scripts](https://github.com/TES3MP/CoreScripts).
Remaining gameplay problems mostly relate to AI and the synchronization of clientside script variables.
Donations
---------------
[Serverside Lua scripts](https://github.com/TES3MP/PluginExamples) are used to save and load the state of most of the aforementioned.
You can benefit the project by donating on Patreon to our two developers, [David Cernat](https://www.patreon.com/davidcernat) and [Koncord](https://www.patreon.com/Koncord), as well as by supporting [OpenMW](https://openmw.org).
Contributing
Contributing
--------------
---------------
Development has been relatively fast, but any contribution regarding [code](https://github.com/TES3MP/openmw-tes3mp/blob/master/CONTRIBUTING.md), documentation, bug hunting or video showcases is greatly appreciated.
Helping us with documentation, bug hunting and video showcases is always greatly appreciated.
Test sessions are often advertised in [our Steam group](https://steamcommunity.com/groups/mwmulti) or [our Discord server](https://discord.gg/H8zhhuk).
For code contributions, it's best to start out with modestly sized fixes and features and work your way up. There are so many different possible implementations of more major features – many of which would cause undesirable code or vision conflicts with OpenMW – that those should be talked over in advance with the existing developers before effort is spent on them.
Feel free to contact the [team members](https://github.com/TES3MP/openmw-tes3mp/blob/master/tes3mp-credits.md) for any questions you might have.
Feel free to contact the [team members](https://github.com/TES3MP/openmw-tes3mp/blob/master/tes3mp-credits.md) for any questions you might have.
Getting Started
Getting started
---------------
---------------
* [TES3MP section on OpenMW forums](https://forum.openmw.org/viewforum.php?f=44)
* [Steam group](https://steamcommunity.com/groups/mwmulti) and its [detailed FAQ](https://steamcommunity.com/groups/mwmulti/discussions/1/353916184342480541/)
* [TES3MP section on OpenMW forums](https://forum.openmw.org/viewforum.php?f=45)
* [Discord server](https://discord.gg/ECJk293)
* [Subreddit](https://www.reddit.com/r/tes3mp)
* [Subreddit](https://www.reddit.com/r/tes3mp)
* [Installation and build instructions](https://github.com/TES3MP/openmw-tes3mp/wiki/Installation-and-build-instructions)
* [Known issues and bug reports](https://github.com/TES3MP/openmw-tes3mp/issues)
* [Known issues and bug reports](https://github.com/TES3MP/openmw-tes3mp/issues)
Donations
---------------
You can benefit the project by contributing to the Patreon pages of our two developers, [Koncord](https://www.patreon.com/Koncord) and [David Cernat](https://www.patreon.com/davidcernat), as well as by supporting [OpenMW](https://openmw.org).
David Cernat
uramer
Koncord
Koncord
terrabyte25
Testman
Grim Kriegor
Sam Hellawell
Marc Zinnschlag
Andrei Kortunov
Bret Curtis
Capostrophic
Capostrophic
AnyOldName3
Ryan Tucker
Miloslav Číž
Nikolay Kasyanov
elsid
terrabyte25
Alexander Stillich
Alex S
Joakim Berg
David Walley
Thunderforge
Finbar Crago
Bret Curtis
Xenkhan
AnyOldName3
Atahualpa
Adam Bowen
rhtucker
Capostrophic
wareya
Cédric
AnyOldName3
scrawl
declan-millar
Nelsson Huotari
Alexander "Ananace" Olofsson
tri4ng1e
Kyle Cooley
Alf Henrik Sauge
Evgeny Kurnevsky
Andreas Sturmlechner
Ilya Zhuravlev
Simon
RoadTrain
Harald H
Chris Robinson
Florian Weber
Daniel Vukelich
Allofich
Grigorii Latyshev
jbo-85
rexelion
Miloslav Číž
David Walley
AnyOldName3
Marcin Baszczewski
lukago
Rhiyo
Miloslav Číž
Nikolay Kasyanov
HiPhish