View Issue Details

IDProjectCategoryView StatusLast Update
0006426Multi Theft Auto : San AndreasServerpublic2011-12-12 08:36
ReporterNeO_D-Power Assigned ToMr.Hankey  
Status resolvedResolutionfixed 
PlatformMTA:SA 1.1OSMicrosoft WindowsOS Version7 Ultimate x64
Target Version1.2Fixed in Version1.2 
Summary0006426: resetMapInfo sets the level of the predefined water bodies and pools to the sea level

It seems that resetMapInfo() sets the levels of the pre-defined water bodies (water bodies that were not created by a user or a resource, such as ponds and pools from the original map) to the sea level.

I think it is best if these water bodies stay at their predefined levels, as they used to in 1.0

Steps To Reproduce
  1. Start a server without any resources that rely on resetMapInfo()
    Note: it is important that mapmanager should not start, as it triggers the resetMapInfo() function
  2. Start freeroam and runcode resources
  3. Type /run resetMapInfo() and /run fadeCamera(true) to fade camera back in
  4. Observe the water level

Points of observation: The Sherman Dam reservoir, ponds at LV casinos, ponds in Foster Valley (just outside San Fierro), various pools by the houses next to the mansions, etc...

Additional Information

I think it may have something to do with MrHankey's update r1863 for the issue #4361
resetMapInfo was working properly in 1.0.5 (and older builds)

This issue is quite big because of the maps built around those ponds.
Besides, recreating the water levels for these ponds and pools would take quite a lot of work and time.

TagsNo tags attached.


related to 0004361 resolvedccw Water elements destroyed through resetMapInfo do not reappear 



2011-08-27 21:10

viewer   ~~0014506

Not sure if related, but a small body of water that used to be slightly inclined near the docks is now perfectly flat:

Up until 1.0.5 it appeared as expected:


2011-08-27 23:18

viewer   ~~0014510

I spoke with MrHankey, he said it might be related...
I did notice the water level is slightly higher than in 1.0


2011-09-09 18:04

reporter   ~~0014754

^ Slightly higher?:


2011-09-23 01:39

viewer   ~~0014870

Despite r1863 being reverted, this bug still occurs in the latest nightly (r3215).


2011-09-24 20:25

viewer   ~~0014909

Apparently fixed in client r3227.


2011-12-12 08:36

administrator   ~~0015352

Fixed in

Issue History

Date Modified Username Field Change