Plots corrupting upon unclaiming with revert

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create town
2. /town claim auto
3. /town delete

What is the expected output? What do you see instead?
Look at screenshots from game.

What is your towny build?
0.80.0.0
What is your bukkit build?
2126
What operating system?
Windows 7 x64
Please use pastebin.com to attach links to relevant files which could
include your towny config.yml, your permissions file, broken town files
that prevent towny from loading on startup.

Original issue reported on code.google.com by serverow...@gmail.com on 6 Apr 2012 at 11:24

Attachments:

• 2012-04-06_14.21.01.png
• 2012-04-06_14.21.21.png
• 2012-04-06_14.21.45.png
• 2012-04-06_14.21.51.png

[GoogleCodeExporter]

I just did exactly as you described. and nothing untoward happened.
I did deposit 1000 into the town so '/town claim auto' worked is all that was 
different.

Original comment by Elg...@palmergames.com on 6 Apr 2012 at 4:47

• Changed state: Need_Feedback

[GoogleCodeExporter]

Firstly create a town, then make deposit and /town claim auto, after this type 
/town delete and wait.

Original comment by serverow...@gmail.com on 7 Apr 2012 at 10:25

[GoogleCodeExporter]

I did. It works perfectly.

Original comment by Elg...@palmergames.com on 7 Apr 2012 at 12:00

[GoogleCodeExporter]

I'm still unable to replicate this.
Are you using any plugin which alters the max height of the world?

Original comment by Elg...@palmergames.com on 16 Apr 2012 at 3:17

[GoogleCodeExporter]

Issue 905 has been merged into this issue.

Original comment by Elg...@palmergames.com on 16 Apr 2012 at 3:18

[GoogleCodeExporter]

Changing title

Original comment by Elg...@palmergames.com on 16 Apr 2012 at 3:23

• Changed title: Plots corrupting upon unclaiming with revert

[GoogleCodeExporter]

Seems I got merged into here. Anyway: Same problem, would like to see it fixed.

Original comment by lolm...@gmail.com on 16 Apr 2012 at 4:40

[GoogleCodeExporter]

I'm still unable to replicate this. It works perfectly here.

Original comment by Elg...@palmergames.com on 16 Apr 2012 at 5:10

[GoogleCodeExporter]

Well, that's weird then I guess. You can come try it out if you want.. I'd have 
to whitelist you first though.

Original comment by lolm...@gmail.com on 16 Apr 2012 at 8:44

[GoogleCodeExporter]

ok, try the latest dev. This 'should' be fixed.

Original comment by Elg...@palmergames.com on 19 Apr 2012 at 1:03

[GoogleCodeExporter]

Issue 954 has been merged into this issue.

Original comment by Elg...@palmergames.com on 24 Apr 2012 at 8:11

[GoogleCodeExporter]

Issue 967 has been merged into this issue.

Original comment by LlmD...@gmail.com on 24 Apr 2012 at 8:12

[GoogleCodeExporter]

EXACT SAME THING ON MY SERVER... idk if it is fixed though since i updated it 
yesterday

Original comment by kdungsoc...@gmail.com on 24 Apr 2012 at 8:53

[GoogleCodeExporter]

Ya I got merged in here too.... same problem.... and i hate it.... 
^^^^^^^^^^^^^^^^^^

Original comment by kdungsoc...@gmail.com on 24 Apr 2012 at 8:54

[GoogleCodeExporter]

Something about your setups is corrupting the reported world height. Perhaps 
you can confer and try to find the similarity between your systems? Plugins, 
utils you have run, world mods etc.

Original comment by Elg...@palmergames.com on 24 Apr 2012 at 9:03

[GoogleCodeExporter]

Should updating towny to the newest update help? 

Original comment by kdungsoc...@gmail.com on 24 Apr 2012 at 11:16

[GoogleCodeExporter]

Yes, this has been fixed in the dev, but not in the release.

Original comment by RoganMcL...@gmail.com on 25 Apr 2012 at 2:48

[GoogleCodeExporter]

This happpend to me too

Original comment by quackme....@gmail.com on 25 Apr 2012 at 6:29

[GoogleCodeExporter]

Is there a link to get the lastest dev build i'm pretty new to this.

Thanks.

Original comment by glucas...@live.nl on 25 Apr 2012 at 10:10

[GoogleCodeExporter]

link is in teh main forum post.

http://palmergames.com/downloads

Original comment by Elg...@palmergames.com on 25 Apr 2012 at 12:24

[GoogleCodeExporter]

i updated it to the newest dev build and it is still happenening
PLEASE HELP

Original comment by kdungsoc...@gmail.com on 26 Apr 2012 at 3:13

[GoogleCodeExporter]

wait maybe that was an old thing... nvm

Original comment by kdungsoc...@gmail.com on 26 Apr 2012 at 3:18

[GoogleCodeExporter]

ITS STILL HAPPENING
PLEASE HELP

Original comment by kdungsoc...@gmail.com on 28 Apr 2012 at 3:44

[GoogleCodeExporter]

This happens for me too on the latest dev build still :/

Original comment by peew...@gmail.com on 29 Apr 2012 at 9:40

[GoogleCodeExporter]

I can't help until you all find what is identical between your systems. It only 
happens for you and it's something causing bukkit to report an invalid world 
beight.
It's some plugin or utility you are all using which is messing things up.

Original comment by Elg...@palmergames.com on 29 Apr 2012 at 1:15

[GoogleCodeExporter]

I shall investigate this for you further. This biggest culprit to mind would 
most likely be the Ptweaks plugin, but I'll have a look.

Original comment by peew...@gmail.com on 29 Apr 2012 at 2:48

[GoogleCodeExporter]

If you look at #905 (which was merged into this one) you can see my servers 
plugin list.

Original comment by lolm...@gmail.com on 29 Apr 2012 at 10:22

[GoogleCodeExporter]

Comment 8 by lolmewn, Apr 15, 2012

Plugins:
BKCommonLib
Buycraft
ChestShop
CommandBook
Courier
Dynmap-Towny
Dymmap
FalsebookBlock
FalsebookCore
HeroChat
iConomy
LogBlock
LogBlockQuestioner
LWC
MinecraftRKitPlugin
Minequery
Modifyworld
MultiInv
MultiVerse-Core
NoCheat
NoLagg
NoLaggChunks
NoLaggExamine
NoLaggItemBuffer
NoLaggItemStacker
NoLaggLightning
NoLaggMonitor
NoLaggTNT
Orebduscator
PermissionsEx
Questioner
Register
ReportRTS
SignColours
Skillz
Sortal
spacebukkit
Towny
Vault
WorldEdit
WorldGuard

Original comment by Elg...@palmergames.com on 30 Apr 2012 at 4:39

[GoogleCodeExporter]

A plugin list from sas41

Backup.jar
boosCooldowns.jar
ChatManager.jar
ChestShop.jar
dynmap.jar
Dynmap-Essentials.jar
dynmap-mobs.jar
Dynmap-Towny.jar
Essentials.jar
EssentialsChat.jar
EssentialsProtect.jar
EssentialsSpawn.jar
166я222 iConomy.jar
iZone.jar
Jobs.jar
KeepItems.jar
LogBlock.jar
LogBlockQuestioner.jar
LWC.jar
MagicSpells.jar
MagicSpellsMemory-1.2.jar
Modifyworld.jar
MonsterApocalypse.jar
NoCheat.jar
PermissionsEx.jar
PlayerInfo.jar
PlayerLogger.jar
Questioner.jar
RealBiomes.jar
RealWinter.jar
Register.jar
Runecraft-2.11.1.jar
Safe Creeper.jar
SafeFire.jar
SetRankPEX.jar
Towny.jar
TownyChat.jar
Vanilla.jar
Vault.jar
Votifier.jar
WorldBorder.jar
WorldEdit.jar
xAuth.jar

Original comment by Elg...@palmergames.com on 30 Apr 2012 at 1:54

[GoogleCodeExporter]

I have tried this with all the plugins disabled, except:
Towny.jar
TownyChat.ar
and the dependencies listed at: http://palmergames.com/downloads/.

This map has been with us since 1.0.
Could the height somehow be hard coded into the world save at 128 still?

Original comment by peew...@gmail.com on 30 Apr 2012 at 3:05

[GoogleCodeExporter]

Issue 989 has been merged into this issue.

Original comment by Elg...@palmergames.com on 1 May 2012 at 4:39

[GoogleCodeExporter]

From Williamb

AuthMe
AutoMessage
BKCommonLib
BorderGuard
ChatManager
ChestShop
iConomy
IPCompare
Lift
ModifyWorld
NoLagg[Examine/ItemBuffer/ItemStacker/Lighting/Monitor/TNT]
Orebfuscator
PermissionsEx
Questioner
Register
Towny, TownyChat
Vault

Original comment by Elg...@palmergames.com on 1 May 2012 at 4:40

[GoogleCodeExporter]

The only plugin I see thats common across you all (so far) is modifyworld, a 
part of PEX.

Original comment by Elg...@palmergames.com on 1 May 2012 at 4:41

[GoogleCodeExporter]

Hi,

The plugins i may suspect doing this can be may

- worldguard ( what can be quite strange )
- multiworld ( there whas almost the same bug with this plugin when you 
generated flatland they said it whas the bukkit code change)
- Essentials groupmanager ( this one had problems in the past, and maybe still 
haves incompataiblillity )

so i'm just thinking the 1.2 world has been generated before the whole bukkit 
code changed, so i guess they also changed the height again? should i try to 
make the height like 1.7.3 beta for futher testing, I guess my worlds is half 
corupted can this be true?, and is there a way to convert them to the newest 
version i heard something about forge but I'm not sure it is a converter?

Regards,

Guido

Original comment by glucas...@live.nl on 2 May 2012 at 11:49

[GoogleCodeExporter]

Ok,

I have recompiled the plugin from source, with the height hardcoded, rather 
than using the bukkit getMaxHeight function.

I can therefore conclude that this is not due to an invalid height being 
reported.

Is this tested under Java 6 or 7 and x86 or x64?
I am running this against Java 7 x64, I am thinking maybe this is an issue.

Original comment by peew...@gmail.com on 2 May 2012 at 12:23

[GoogleCodeExporter]

I seem to have found a fix and have it working!!

Let me investigate a little further before I report my findings.

Original comment by peew...@gmail.com on 2 May 2012 at 1:09

[GoogleCodeExporter]

Hi Guys,

Sorry for the delay, I have other work commitments and didn't get chance to 
post back in time.

The problem seems to lie in the TownyFlatFileSource.java package.
The world height is saved in each plot-block-data file, but for some reason 
when reading the file (for example when unclaiming the block) it reads the 
height incorrectly.

At 1st I thought it may be setting the height incorrectly each time it wrote a 
plot-block-data file, but the problem still persisted even when manually 
setting the height to 255.

As a temporary fix I have changed two lines of code in the 
TownyFlatFileSource.java package:

Line 2004: plotBlockData.setHeight(fin.read());
To:        >>>>>>plotBlockData.setHeight(255);

Line 2014: plotBlockData.setHeight(key[0]);
To:        >>>>>>plotBlockData.setHeight(255);

This obviously doesn't resolve the route problem of it not reading the height 
from the plot-block-data file correctly in the 1st place, but it does 
temporarily resolve the situation on my server, and hopefully help point the 
author in the right direction.

If anyone needs a temporary solution whilst this is being fixed, my version of 
jar file can be found here: http://dl.dropbox.com/u/28291774/Towny.jar (it 
literally only has those two lines of code changed).

Hope this is of some help, I'm afraid I don't have much free time on my hands.

Original comment by peew...@gmail.com on 2 May 2012 at 11:30

[GoogleCodeExporter]

Hard coding the height does stop the issue happening, but the problem is the 
incorrect height is being written to the file. The incorrect height seems to be 
fetched from Bukkit.
Another user sent me one of thie data files and the height in it was incorrect.

This seems to only affect a select few people so it's something specific to 
your setups. This is what we need to find. The comonality betwene you.

Original comment by Elg...@palmergames.com on 3 May 2012 at 12:29

[GoogleCodeExporter]

Hello,

I just got a idea what may happend I changed the height in the mayor bukkit 
server.proporties to the max height what is updated in the minecraft 1.2 
client(side)
as default it whas the normal height of 1.7.3 beta 

maybe this is the problem does anyone also changed the server proporties and 
have the same problem aswell?

regards,

Guido

Original comment by glucas...@live.nl on 3 May 2012 at 5:30

[GoogleCodeExporter]

Issue 1001 has been merged into this issue.

Original comment by LlmD...@gmail.com on 3 May 2012 at 9:05

[GoogleCodeExporter]

As I've stated before, the problem is in the TownyFlatFileSource.java package 
itself.

You can even comment out
Line 2004: plotBlockData.setHeight(fin.read());
Line 2014: plotBlockData.setHeight(key[0]);

And it fixes the problem, because the height is initialised in the 
PlotBlockData constructor on line 32: 
setHeight(townBlock.getWorldCoord().getBukkitWorld().getMaxHeight() - 1);

This line of code works fine! It is within the TownyFlatFileSource.java package 
where the problem seems to lie.

I've actually recompiled the jar now, with lines 2004 and 2014 commented out 
and it works still.

There is no hardcoded height!

The issue seems to be in writing the height to the data file, but it is not 
neccessary to read and write the height to the data file anyway (at least not 
in my case).

Original comment by peew...@gmail.com on 4 May 2012 at 2:37

[GoogleCodeExporter]

I have found the solution to the problem.

The problem lies in the use of the BufferedFileWriter and BufferedFileReader 
within the savePlotData and loadPlotData functions of the 
TownyFlatFileSource.java package.

The problem with using these functions for the raw plot-block-data, is that 
they are 'encoding-aware' and what happens with these functions when writing 
integer values is that they are stored as their char equivalents which can 
transform the data passed through them to match the character encoding.

Now the problem with this, is that it is dependent on the encoding used, and 
this seems to vary amongst systems. My system for example, will limit the value 
to 3F (a question mark) after the integer value goes above 127 (which is what 
the height was originally set at until the 1.2 height change).

You can see someone else encountering this issue in their java code: 
http://stackoverflow.com/questions/9398219/why-does-out-write-alter-int-values-i
n-java

Now the simple solution to this is to simply use the BufferedOutputStream and 
BufferedInputStream functions instead of the BufferedFileWriter and 
BufferedFileReader functions within savePlotData and loadPlotData. These 
functions are used for reading/writing 'raw' data to/from files, and will NOT 
transform the data to match the encoding, thus solving the issue!

The height saved to the plot-block-data files was limited due to the file 
encoding, and so was apparent on some machines and not others.

I will attach the altered source code and a link to a fixed jar in a bit =).

Original comment by peew...@gmail.com on 5 May 2012 at 2:31

[GoogleCodeExporter]

Issue 1007 has been merged into this issue.

Original comment by LlmD...@gmail.com on 5 May 2012 at 12:19

[GoogleCodeExporter]

"Comment 41 by peewi96, Yesterday (25 hours ago)

As I've stated before, the problem is in the TownyFlatFileSource.java package 
itself.

You can even comment out
Line 2004: plotBlockData.setHeight(fin.read());
Line 2014: plotBlockData.setHeight(key[0]);

And it fixes the problem, because the height is initialised in the 
PlotBlockData constructor on line 32: 
setHeight(townBlock.getWorldCoord().getBukkitWorld().getMaxHeight() - 1);

This line of code works fine! It is within the TownyFlatFileSource.java package 
where the problem seems to lie.
"

@peewi96 thate fine commenting out that line so it never reads the height from 
the file, however, it will break ALL non 256 height images, as it will then try 
to revert them using a 256 height when it should be using the files settings.

That is only a hack/fix. We need to find the root cause of the wrong height 
being reported to fix this, not fix the symptom.

Also, stop posting links to and distributing your modified jar without 
permission please.

Original comment by Elg...@palmergames.com on 5 May 2012 at 4:26

[GoogleCodeExporter]

Thank you @glucassen@live.nl,

Could everyone please chest their server.properties for the following setting...

max-build-height=256

Original comment by Elg...@palmergames.com on 5 May 2012 at 4:28

[GoogleCodeExporter]

I identified the root cause of the problem in comment 42, please read above.

I have been trying to help you find the root cause of the problem without doing 
it for you. I have not been suggesting these hacks as genuine fixes, but in an 
attempt to show you where the root cause of the problem lies.

The solution is attached to this comment, and is the TownyFlatFileSource.java 
package with the required changes to fix the problem.

Once again, BufferedFileWriter and BufferedFileReader are 'encoding-aware' this 
is why the height saved to the plot-block-data file is incorrect on some 
systems and not others, this has only sprung up since the 1.2 height change due 
to the fact that 127 is still within the ascii char range.

Original comment by peew...@gmail.com on 5 May 2012 at 5:12

Attachments:

• TownyFlatFileSource.java

[GoogleCodeExporter]

I've not used Github before but I've managed to fork it if you wish to see the 
commit.

Original comment by peew...@gmail.com on 5 May 2012 at 5:32

[GoogleCodeExporter]

Issue 1009 has been merged into this issue.

Original comment by LlmD...@gmail.com on 6 May 2012 at 1:44

[GoogleCodeExporter]

I have followed Peewi's instructions and it has fixed the problem for me, and 
towny now works fine. Please try and follow it if you want to fix the problem.

Original comment by elliotp....@gmail.com on 6 May 2012 at 4:57

[GoogleCodeExporter]

@peewi96 thanks I'd not seen your post before my last comment. That does fit. 
I'll fix in source.

Original comment by Elg...@palmergames.com on 6 May 2012 at 11:42