Entering cave, map remains on surface

[Fostik]

Naht fixed.
Some bugs with map loading. http://c2n.me/3pRDkEm

[marvi]

It's an issue with the custom client.

(also, try to update client now, it should be fixed)

[MagicManICT]

Merged several of the "cave map still showing on surface" threads.

[mipmiopin]

After this new juicy update i rushed in the mines to diggy a hole, and some dug tiles do not change their appearance.

[jorb]

After this new juicy update i rushed in the mines to diggy a hole, and some dug tiles do not change their appearance.

Update your client.

[Gunner53]

Yea I had this problem with the standard as well, but maybe the last patch fixed it? I have not had the problem since, but I am having some issues with loading the new maps when entering/exiting houses as well as caves.

[loftar]

Yea I had this problem with the standard as well, but maybe the last patch fixed it? I have not had the problem since, but I am having some issues with loading the new maps when entering/exiting houses as well as caves.

You are actually one of the primary causes of the current server lag, since your client is totally spamming the server with map requests. May I ask what client you are using?

[Granger]

@Loftar: would it be reasonable to ask client builders to transmit client name and version (build timestamp) on connect to ease debugging of such problems (or for you to be able to deliver a message to all users of a certain client in case a problem with it manifests)?

[loftar]

@Loftar: would it be reasonable to ask client builders to transmit client name and version (build timestamp) on connect to ease debugging of such problems (or for you to be able to deliver a message to all users of a certain client in case a problem with it manifests)?

That would probably be helpful, but I don't expect custom clients to do that in actual practice. I imagine most authors simply won't even notice that they should change whatever the code says to their own ID string, even before they render it a conscious choice.

[marvi]

That would probably be helpful, but I don't expect custom clients to do that in actual practice. I imagine most authors simply won't even notice that they should change whatever the code says to their own ID string, even before they render it a conscious choice.

Maybe instead of hardcoding it's better to add this info to the JAR's manifest during build?

To illustrate the idea, build.xml can be modified like this: https://gist.github.com/k-t/467535ea3f7c9364b832

Then all is needed is to set up proper environment variables on the build machine and pull this info from the manifest at runtime. At the very least it should help to determine whether client is custom or not, unless someone intentionally masks as such.