search

multitheftauto / mtasa-blue

Multi Theft Auto is a game engine that incorporates an extendable network play element into a proprietary commercial single-player game.
https://multitheftauto.com
GNU General Public License v3.0
1.41k stars 438 forks source link

Objects are not created in correct dimension #640

Closed Str0 closed 6 years ago

Str0 commented 6 years ago

Describe the bug

Certain Map-Objects that have a dimension above zero are not created correctly in versions newer than 1.5.6-9.14640.0

Any object with the dimension-tag greater than zero is created in dimension 0.

The above object is not created in dimension 12 but oddly in dimension 0.

To reproduce

Update to any recent version. Update the default resources. Create a map with an interior above zero as well as a dimension above zero. Checkout said map.

Expected behaviour

The map-object should be created at the given location, dimension, interior.

Version 1.5.6-9.14664.0

Additional context

The reason why I created an issue within the mtasa-blue section rather than the resources one is due to the reason that there is no diff in the new resources and the old ones leaving me wondering wether this is maybe an mtasa-issue or not.

ArranTuna commented 6 years ago

Are you sure that 14640 is the build the bug was introduced? Looking at https://buildinfo.mtasa.com/index.php it would seem unlikely that this exact build would be when the bug is introduced.

Dutchman101 commented 6 years ago

Are you sure that 14640 is the build the bug was introduced? Looking at https://buildinfo.mtasa.com/index.php it would seem unlikely that this exact build would be when the bug is introduced.

Unlikely? This commit: https://github.com/multitheftauto/mtasa-blue/commit/81b5ba259dcc5eb9c6cfbaf19d119d4c654d4150 which is included in that build, changes stuff related to .map files, so I think it's worth looking at.

ArranTuna commented 6 years ago

That commit is listed as being in 14662 though.

Dutchman101 commented 6 years ago

That commit is listed as being in 14662 though.

ah, my bad - I was confusing r14640 for r1466x.. it's possible that @Str0 also did, so let's wait for his reply on your question. Trying to reproduce ourselves would be much quicker but I'm not currently able to.

Str0 commented 6 years ago

The commit on 81b5ba2 seemed very likely to me.

Unfortunantly I am not able to tell the exact version as the server didn't pull each new build everyday and there was some gap between the versions.

Seeing the commit that was posted here I am however thinking as well that 14662 was the cause.

Dutchman101 commented 6 years ago

The commit on 81b5ba2 seemed very likely to me.

Unfortunantly I am not able to tell the exact version as the server didn't pull each new build everyday and there was some gap between the versions.

Seeing the commit that was posted here I am however thinking as well that 14662 was the cause.

@botder is on it, he'll verify shortly as he told me. This would be quite a nasty bug if true..

Str0 commented 6 years ago

@Dutchman101 Sounds perfect, thanks for the efforts!

Didn't look into createFromXML(...) myself yet.

botder commented 6 years ago

I would like to mention that the editor resource fails to store the correct dimension in the resulting .map file. I tried it with the latest and older default resource package, both yielded the same result.

Dutchman101 commented 6 years ago

I would like to mention that the editor resource fails to store the correct dimension in the resulting .map file. I tried it with the latest and older default resource package, both yielded the same result.

In addition, does the issue only occur in server r14662 and up, or also on slightly older builds?

botder commented 6 years ago

The commit fixed the issue with map loading. The resource editor_main (part of editor package, in function createElementAttributesForSaving in file server/saveloadtest_server.lua) still has the dimension saving issue.