A developer overview of tes3mp's status, goals & challenges

Everything having to do with OpenMW's TES3MP branch.
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

A developer overview of tes3mp's status, goals & challenges

Post by davidcernat »

Note: This post is out of date. You should read it mostly if you want to know what my thoughts were back in February of 2017.


Hello there, OpenMW forums. At the behest of psi29a, and with the approval of the OpenMW leadership, a new subforum has been created for tes3mp. I wish to extend my gratitude to everyone involved in that decision. OpenMW is one of the greatest open source projects and communities I have ever come across, I have thoroughly enjoyed working with its code, and I am humbled to see our fork become part of it in a more official capacity.

For my first post on this subforum, I would like to go through tes3mp's history thus far, its current set of features, the discrepancies between it and OpenMW, and some of the issues we will be facing in its future.


Introduction

tes3mp is a fork of OpenMW started in December of 2015 and made public in July of 2016 that intends to add a seamless multiplayer experience to your project, the kind that fans of Morrowind have dreamt of playing with their friends and families since 2002.

I am one of its two developers along with Koncord, and – as a hypothetical pull request from us would reveal – we have thus far added 42,915 lines of code to our fork that don't exist in OpenMW.

It was Koncord alone who worked on tes3mp during its first seven months and came up with most of its architecture, drawing inspiration from projects like San Andreas Multiplayer and the Vault-Tec Multiplayer Mod for Fallout 3, having himself been a developer on the latter.

With so little development time, however, his initial release of the code on GitHub in July 2016 was simply a proof of concept for player synchronization. Players were able to see each other's movements, animations, equipment changes and melee attacks quite well in interior cells, but there were certain glaring problems, such as the inability of players to ever see each other again after moving across exterior cells, the lack of state saving, and a plethora of graphical glitches that ranged from Khajiit players intially spawning as Dark Elves with misshapen tails to players completely losing all animation after putting on armor. It was also near-impossible to build tes3mp's server app on Windows, with it using a C++14 feature that was not supported in Visual Studio 2015 and a dependency that could not be built in MinGW-w64 (a Lua replacement named terra).

That's where I came in. Although tes3mp could not live up to the hype already created around it, I noticed its networking and packet systems were very sound, its Lua scripting system was quite promising, its desire to keep most multiplayer logic separate from OpenMW's code allowed it – in theory – to effortlessly take in almost all changes made to OpenMW, and the fact that it was based on a well-made C++ recreation of an Elder Scrolls game's engine meant it would avoid some of the unsolvable difficulties that had plagued previous fanmade multiplayer attempts.

For those reasons, I've been fixing it and adding features to it with Koncord ever since, as well as providing most of its planning and conceptual direction.


Current status

To quote what I've written in our Steam group's FAQ:
Player movements and cell changes are very well synchronized. You can go anywhere on Vvardenfell and meet up with other players correctly. You can even load up Tamriel Rebuilt, give yourself a massive Acrobatics skill using the console, jump across the entire width of Morrowind a few times and meet up with a player doing the same.

Player equipment, stats, combat and spell casting are also well-synchronized. Player stats, inventories and spellbooks are saved to and loaded from the server.

Picking up or dropping items in the world makes them appear and disappear correctly for other players, including in containers, as does spawning and deleting objects via the console, and their state will get saved to the server and then loaded for new arrivals. Opening, closing, unlocking and locking doors is synchronized and their changing states are saved to the server. Using certain buttons and levers – like the ones at Ghostgate, Dwemer ruins or Sotha Sil's Clockwork City – is also synchronized, although their state is not yet saved to the server.

However, other important aspects of the game are not yet synchronized, saved or loaded, including NPCs, time, weather, quest states, dialogue topics, bounties, faction membership, and the vast majority of ingame scripts.
In addition to the gameplay features mentioned above, we also have a server browser and a master server, allowing players to easily find and connect to each other.

We also have fully working ingame chat, as well as chat commands that run serverside Lua scripts.


Additions to OpenMW

The most immediately noticeable additions are two new apps: openmw-mp (which contains the code for tes3mp-server) and browser (the code for tes3mp-browser).

We also have two new dependencies: RakNet (our networking middleware) and Lua (our serverside scripting language). Lua can optionally be replaced with terra in Linux builds. RakNet is required by our client, server and browser, while Lua is only required by the server.

tes3mp adds a folder named openmw-mp to OpenMW's components. Inside it are classes for packets, packet controllers and the base objects whose data is sent via packets, and they are all used by both the client and the server.

tes3mp also adds a new folder named mwmp to the openmw app. In an attempt to prevent the multiplayer code from spilling into the rest of openmw, it contains most of the functionality for reading and sending packets on the client, handling our own GUI elements, continuously checking the local player's state, updating the NPC representations of other players, finding and making changes to objects in the world.

Any installation of the tes3mp server also requires a folder, with a customizable name, inside whose subfolders the Lua scripts, Lua libraries and server data can be stored.


Modifications to OpenMW

That being said, there have been some unavoidable modifications in the rest of the openmw app. A few notable examples follow:

The player spawns in Pelagiad for now instead of the Imperial Prison Ship or OpenMW's other default spawn point of exterior cell 0, 0.

The menu screens for saving and loading the game are gone, and both quicksaving and quickloading are disabled.

The booleans tracking whether the game should be paused have been changed so they are always false.

Most methods dealing with changes made to the world – such as when items are picked up or dropped – tend to have extra lines of tes3mp code that send a packet about what has taken place. Additionally, places where changes to the player happen that should not be checked every frame in a separate loop – such as inventory or spellbook changes as opposed to position or animation changes – also have accompanying code.

A boolean named canChangeCell has been added to MWWorld::LiveCellRefBase that determines whether an object is allowed to move to another cell in World::moveObject() – so as to prevent the client from doing momentum-based cell transitions that have not been approved by the server.

A boolean named sendPackets has been added to InterpreterContext that determines whether script value packets should be sent for the script attached to it. Script whitelists and blacklists are thus made possible.

Code making NPCs use random attacks, auto-equip items and report crimes has had additional conditions added to it to prevent if from affecting player-controlled NPCs.

Code related to combat and spellcasting has been modified to ensure that hit success and damage is not recalculated on every client.

In OpenMW, placing or spawning an object in the world gives it a reference number of 0. To allow players to send each other packets about newly placed or spawned objects, we have had to assign them reference numbers on the fly.

A relatively small number of methods have been added to existing classes whenever they have simplified aspects of tes3mp. Examples include LocalMapBase::updatePlayerMarkers(), MapWindow::updatePlayerMarkers(), MWMechanics::NpcStats::setLevelProgress(), MWMechanics::NpcStats::getSkillIncrease(), MWMechanics::NpcStats::setSkillIncrease(), World::saveDoorState(), CellRef::setRefNumIndex(), CellStore::getContainers() and CellStore::searchExact().


Current direction

Our main goal right now is the implementation of NPC synchronization, traditionally the greatest challenge for fanmade multiplayer. Having considered possible approaches to it for a while, we are one burst of activity away from our first take on it, which will involve clients splitting the processing of NPCs among each other. We may move to serverside AI in the future, though doing so would make for a massive divergence from OpenMW code, as well as potentially requiring faster, more powerful servers, which is why we should only do it after careful deliberation.

Our secondary goal is making our server data get stored in an SQL database instead of the temporary text files we are using right now. Doing so will allow us to add timestamps to every change made in a cell since the start of the current server session, which in turn will allow us to send cell data to players on a more need-to-know basis.

The synchronization of quests, dialogue topics, faction membership, reputation and bounties should be much easier to do, but will only become relevant once NPCs are working.

Time and weather require divergence from OpenMW's code, which is why we have avoided doing them so far, though they should also be easy in practice.


One unique challenge

The greatest challenge for tes3mp will probably be the finding of a comprehensive solution for script synchronization. For certain scripts in the game, we can simply send a packet to other players whenever a short value in the script changes or a float gets set to a value without decimals, thus ensuring perfect sync for everyone else in that area with no packet spam. This works great for buttons and levers, like the ones at Ghostgate or in Sotha Sil, and is already implemented for them.

Unfortunately, other scripts in the game – such as banners flapping in the wind or objects floating on water – set values every other frame, and would lead to infinite packet spam if we applied the same system to them that works for others.

Going through all the scripts in the game and manually putting together a synchronization whitelist or a blacklist would probably work for Morrowind and its expansions, but would not provide a solution for all the plugins in existence or for any future projects based on OpenMW.

Some kind of script value spam detector may end up being the best solution, though false positives will be a constant danger.


Thank you for reading all of that. I'll be happy to answer any of your questions.
Last edited by davidcernat on 30 Jul 2017, 02:14, edited 2 times in total.
Biboran
Posts: 84
Joined: 03 Feb 2016, 12:50

Re: A developer overview of tes3mp's status, goals & challen

Post by Biboran »

Wow, awsome! There will be possible to create you own LAN private server to play with friends? :D
It will have options to co-op game, like where if one does quest, same quest will be done for other player?
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

Re: A developer overview of tes3mp's status, goals & challen

Post by davidcernat »

Biboran wrote:Wow, awsome! There will be possible to create you own LAN private server to play with friends? :D
It will have options to co-op game, like where if one does quest, same quest will be done for other player?
Creating your own LAN private server is already possible.

As for quests, we'll have a server setting that allows you to decide whether they are shared or not. We will focus on making shared quests work very well, but if certain servers want to see what happens when quests are not shared, they should have that option.
Biboran
Posts: 84
Joined: 03 Feb 2016, 12:50

Re: A developer overview of tes3mp's status, goals & challen

Post by Biboran »

Thanx! You make really good work guys! :D
User avatar
silentthief
Posts: 456
Joined: 18 Apr 2013, 01:20
Location: Currently traversing the Ascadian Isles

Re: A developer overview of tes3mp's status, goals & challen

Post by silentthief »

This is awesome. Welcome to the forums! Glad you got a section for the tes3mp

ST
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: A developer overview of tes3mp's status, goals & challen

Post by psi29a »

Some additional context, OpenMW saw no harm in giving a portion of the forums to the tes3mp project. This does not mean that OpenMW is committed to tes3mp as "the" MP solution for OpenMW, but if our goals and ideas behind MP align then it would be beneficial to have both projects in one place. :)

For the time being, OpenMW is devoting its time and resources to 1.0 release. After 1.0, we can see about MP.

Even if the two projects can't find common ground on MP, the two projects can live side-by-side and benefit from each other.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: A developer overview of tes3mp's status, goals & challen

Post by raevol »

Welcome to the forums! Really excited about your work, keep it up!
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

Re: A developer overview of tes3mp's status, goals & challen

Post by davidcernat »

Thank you. It's great to receive such a warm welcome.
psi29a wrote:This does not mean that OpenMW is committed to tes3mp as "the" MP solution for OpenMW, but if our goals and ideas behind MP align then it would be beneficial to have both projects in one place. :)
I understand completely.

I'll do my best to move tes3mp closer to OpenMW's standards and way of doing things, and – given our shared preference for cooperative play over MMO-like play – I think we'll find ourselves in full agreement on what the standard and supported style of gameplay should be.

However, should OpenMW create its own separate take on multiplayer, we hope our own efforts will provide some inspiration and useful insights.
onionland
Posts: 68
Joined: 29 Jul 2014, 00:43

Re: A developer overview of tes3mp's status, goals & challen

Post by onionland »

davidcernat wrote: However, should OpenMW create its own separate take on multiplayer, we hope our own efforts will provide some inspiration and useful insights.
Given the incredible progress that you and Koncord have made on tes3mp I can't see any other server wide project attempt to compete with it any time soon. :D
(Personally really holding out for a more simple split screen co-op implementation though, something along the line of Fable2.)

Needless to say though, freakin' awesome job!
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: A developer overview of tes3mp's status, goals & challen

Post by Zini »

This is a repost of something I posted during the internal discussion about how to deal with multiplayer. I think most of my concerns are already addressed. But I'll post it here anyway, so that everyone can see it.
My main concern is still the same. Dealing with MP at this stage in any way will eat man power that we need for other parts of OpenMW. Or rather it may be that we simple do not have the man power to deal with MP at the moment. That being said, I don't think a subforum would cause any harm, as long as it is made clear that MP is currently very low priority for us and we may not always be able to provide assistance in timely manner or sometimes at all.

As for merging the MP fork back in: I don't think we ever promised that such a merge would happen. It depends on if their idea of MP makes sense and fits into our project. I haven't even gotten around to look at that thing. It may be helpful to ask them for a design document that specifies exactly what they understand under MP and which changes to the basic structure of OpenMW are required to support it.

I am pretty sure that MP is possible at least from a design standpoint. But there is really only one option. One main player and the other players act as a player-equivalent of NPC-companions (kinda like a party).
They would have to share a single quest state and probably also things like reputation, criminal status and so on (need to make a list of that at some point).
The implementation of MW content (both original and modded) does not allow for anything else. Any alternative approach would require special MP content instead of the regular content files. That is not something we want.
Even with this approach there might be some problems with the existing content, but these should be minor enough that they can be patched.
Post Reply