Sign in to follow this  
bdew

PSA: Incorrect settings in wurm.ini when upgrading to 1.6 will cause bugs on your server!

Recommended Posts

If you upgraded your server from 1.5 you are likely missing the following important lines in your wurm.ini:

 

# DO NOT ENABLE
USE_SCHEDULED_EXECUTOR_TO_UPDATE_ITEM_OWNER_IN_DATABASE=false
USE_SCHEDULED_EXECUTOR_TO_UPDATE_ITEM_LASTOWNER_IN_DATABASE=false
USE_SCHEDULED_EXECUTOR_TO_UPDATE_ITEM_PARENT_IN_DATABASE=false

 

If they are not present those "features" will be enabled and cause a mess, including possible money duping and items disappearing. 

 

I highly recommend to all server owners check your wurm.ini, and if those lines aren't there - add them and restart your server ASAP.

 

  • Like 7

Share this post


Link to post
Share on other sites

Does it matter where we put those lines in the wurm.ini, or is it fine to just copy and paste them to the bottom of the list?

Also, do we include the line

#DO NOT ENABLE

Edited by Batta

Share this post


Link to post
Share on other sites

 

1 hour ago, Batta said:

Does it matter where we put those lines in the wurm.ini, or is it fine to just copy and paste them to the bottom of the list?

Also, do we include the line

#DO NOT ENABLE

 

Probably anywhere is fine but wait for bdew if you want to be 100% sure, since he is a programmer and I am not. .But if he does not surface within 24 hours or so I would just add at the end and restart the server, since it is a fairly time-urgent matter.

Sometimes there is a specific subsection where something belongs, but he certainly would have said so if that was the case, so anywhere is 99.9999 percent likely fine. If it were my own server, I would add it to the end and not worry about it.

 

 

 

Adding the line #DO NOT ENABLE does not really matter since the purpose of the "#" is to tell the program to IGNORE THIS LINE. So it will work the same with or without that line.

The line is included simply so that people later revising the code, know what was changed and know not to change that section. Since you don;t really understand it anyway, hopefully you would never be editing it to enable. 

But to be safe I would probably include it (sometimes it simply makes it easier to later find that section again, in case you want to recheck for typos/errors)

 

 

Edited by Brash_Endeavors
  • Like 1

Share this post


Link to post
Share on other sites

Yeah they can go anywhere in the file and the #DO NOT ENABLE is a comment so you can skip it if you want (i just copied it verbatim from the original file)

  • Like 1

Share this post


Link to post
Share on other sites

And some details to expand more about what is breaking and why (i was originally writing this post at about 5AM after a "fun" night spent debugging my servers):

 

Having those lines missing or set to true tells the game to write some changes to the items database in a delayed process running on another thread... which is a good thing in theory as it reduces time wasted waiting for IO in the main server loop and could reduce server lag.

 

The fields each line affects are OWNER (means the player/creature that currently has the item in their inventory, id any), LASTOWNER (means the last player that held the item, when you drop an item on the ground - that is what determines that you still "own" it) and PARENT (this is the ID of the container the item is in, for example a player's inventory or a chest).

 

The problems begin when an item that was in a player's inventory changes hands or is moved to a different location. If those lines are enabled - the changes to those fields are not written out immediately to the database and instead are delayed until the next time that the batch process is scheduled to run. But if a player relogs before that, upon logging in all the content of his inventory is read from the database, including the old data describing where the items are that hasn't been updated yet. 

 

This causes all items he traded away to re-appear in their inventory. If he bought something from a trader - he will now have both his money and goods. If he sold something - he will get whatever he sold back, and keep the money. etc.

 

Worse yet this also in many cases leaves a "ghosted" copy of the item in the other place where it was. So now you have 2 items with same ID but different data floating around in your world causing future weirdness.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this