Revert "setWaterLevel: add option to change water level outside world…

[Pirulax]

According to our research over at #development, and thanks to Dutchman's help the issue seems to be caused by this commit. (Since it modifies the MapInfo packet, and even after reverting bd89570 it still exists I presume this is the commit causing the issue).

As of my knowledge the client bitstream version reflects the one the stream was written with.
Eg.: Server is at 0x10, client at 0x20, the bitstream (that is, bitStream.getVersion() on the client) will at most be 0x10.
If not, then this line causes the issue, since a bit might be true at the point when ReadBit is called, which in turn reads 4 bytes (the float), and hence the whole packet is corrupted.

[Pirulax]

Uh, I'm not sure what to do about the bitstream version tho.... Older servers might still write that portion(that is, the bit + float), which would cause newer clients(that is, which have this PR) to crash

[TheNormalnij]

then this line causes

Can you provide better link?

[Pirulax]

Yes,

mtasa-blue/Client/mods/deathmatch/logic/CPacketHandler.cpp

Line 2517 in 94c6aba

pWeaponInfo->SetAccuracy(weaponProperty.data.fAccuracy);

It is the same crash as in #1873

[Pirulax]

then this line causes

Can you provide better link?

Ah, my bad, I see..
This line:

if (bitStream.Can(eBitStreamVersion::SetWaterLevel_ChangeOutsideWorldLevel))

Just search for it, I can't give a link to it, for whatever reason. It's in CPacketHandler::Packet_MapInfo(NetBitStreamInterface& bitStream)

[TheNormalnij]

Why bitStream.Can doesn't work there? Server and client use different bitstream version?

[TheNormalnij]

How to repro related issue?

[Pirulax]

How to repro related issue?

I have no clue. It seems like connecting to a server running an older version (that is, one that doesnt have this commit) will make the client (which has this commit) crash.

That's the part I dont understand either(from the description):

As of my knowledge the client bitstream version reflects the one the stream was written with.
Eg.: Server is at 0x10, client at 0x20, the bitstream (that is, bitStream.getVersion() on the client) will at most be 0x10.
If not, then this line causes the issue, since a bit might be true at the point when ReadBit is called, which in turn reads 4 bytes (the float), and hence the whole packet is corrupted.

[ds1-e]

Yep, connecting is enough to get a crash (i was connecting to server running r20693).

[TheNormalnij]

But i can connect to older MTA version, So bitStream.Can works good here. Maybe r20693 server is broken itself?

[TheNormalnij]

r20693 server and client are unavailable to download. Can we confirm this bug for another versions?

[Pirulax]

They're available for download.
Just go here, and click on:

• show older files

[TheNormalnij]

20694 and 20689 only

[Pirulax]

Interesting.. here, see the Use enum classes for BitStream (#1737).

[TheNormalnij]

check next version Make sure BitStream comparisons still work correctly (#1752)

[TheNormalnij]

I think we can't do this, because servers with SetWaterLevel_ChangeOutsideWorldLevel bitstream version will send SetWaterLevel_ChangeOutsideWorldLevel packets for clients with PedEnterExit version.

[Pirulax]

Turns out the issue is only present in r20693, it was later fixed in r20694.