The 'Black Line' Tile Problem.

[trixiewish 28]

The 'Black Line' Tile Problem.

by tais

So whilst I was busy and away building a phase all fine and all, spending hours on constructing, a server restart had happened. This'd be completely fine if I didn't come back to find black lines between most (but not all) of my tiles. At first, I was confused though I wanted to fix it since it was so aesthetically displeasing. Anyway.. to the report...

The image above is my aforementioned problem. Small black lines between tiles that are all too visible.

Though, after some time testing (and waiting for server restarts) I've found the cause and decided to make this report. The problem stems in the server rounding the positions of the tiles, and due to the nature of characters placing objects in random spots that would most likely be a number that the server will round up/down to. My first thought was to simply use the .worldport command to round the tiles myself though once I had '.go copy for 4' the second object would be a strange float number. 

Thinking of how the world behaves on its xyz, I came to conclude that it all comes down to the orientation of the tiles you put down. This is most noticeable in Light's Harbour where Kitty placed every one of the tiles at the 0.00000 orientation which will not round whatsoever and look flawless after a restart.

The image below shows how the xyz is changed by copying the tile by 4. The underlined red is why angled tiles do not work.

Now, you might just say: 'Hey! Why don't just just always orientate the tiles to the north facing direction all the time?'  but that'd be completely impractical since that limits the designs and creativity you can put into your builds. There are so many applications that these tiles have; all in which involve angled and precise measurements. I'm not sure how/if this could be fixed, though I could only suggest that the degree in which the server rounds up is greatly increased for this not to happen. Just a note to mention, this problem doesn't seem to exist in other similar servers, at least not at this degree of problem.

 

Thanks,

 

[Xeslite 36]

Just gonna point out that this is the best bug report I've ever seen. Good job dude.

[trixiewish 28]

Hey, just want to say that this problem is easily remedied by one simple solution. You can fix this issue my having your .gob copy to be set to 3.99. there will be some minor z-fighting though it is very negligible. My phase now looks spic and span without those pesky lines.

[aurot 9]

You are the sort of bug tester the world needs. You are a good person.

[MindScape 66]

@Azarchius This would be a great fix - precision building with tiles right now is almost impossible with them moving on a server restart.

(I am sure you have more knowledge in this than me but I assume changing the value from float to decimal or real number would allow us to avoid rounding when re-placing the object on a server restart - though might be less efficient?)

Edited December 6, 2017 by MindScape

[Azarchius 212]

Not that simple. We use float. It is not a practical operation to rewrite TrinityCore to use a different one.

 

I will look into why the object spawns as an integer, seemingly, though? However, I should note that objects not adjusting properly is from previous tests because the server can only store up to, uh, 6 digits, I believe it was. This issue is relieved if you simply spawn in coordinates much closer to 0.

 

I'll take this bug report as ".gobject copy is bugged" -- if it converts from float to integer and back to float (for whatever reason, no sensible idea why that would happen) then it can be resolved. But you should know TrinityCore only saves up to 6-7 digits of float. This means that if you spawn too far from the center of the map you will have no hope of building properly. This is an issue in all private servers and a fix is not simple, but it is on the cards.

[Razmataz 14]

Oh! We made object placement a lot more precise, which means the tiny offsets at angles should be resolved. So I'm marking this as fixed. (You may still experience issues at coordinates of >1000, or definitely >10000)