View Issue Details

IDProjectCategoryView StatusLast Update
0006537New Feature Requests[All Projects] Generalpublic2017-06-18 20:56
ReporterRiginOALAssigned To 
PrioritylowSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0006537: [Request] onElementContactWater
Description

An event that's triggered when an element falls into water.

TagsNo tags attached.

Relationships

has duplicate 0008418 closed New issues [Request] onElementContactWater 

Activities

Riaz

2011-09-23 14:15

viewer   ~~0014885

onElement(Enter/Exit)Water maybe?

arranTuna

2011-09-23 14:18

manager   ~~0014887

First of all it would need to be onClient... because the client is aware of this kind of thing but maybe the server won't be.

RiginOAL

2011-09-24 00:50

viewer   ~~0014899

nice idea riaz! you r beyond my thinking

AlexTMjugador

2014-08-02 12:34

viewer   ~~0021620

Last edited: 2014-08-03 12:52

View 2 revisions

This can be easily archieved using Lua by checking if a element is in water or not on the onClientPreRender event:

function checkWaterStatus()
local sunkableElements = { "ped", "player", "vehicle", "object" } -- More element types = more expensive
local elementsToCheck = {}
for , type in ipairs(sunkableElements) do
table.insert(elementsToCheck, getElementsByType(type, true)) -- Only streamed in objects
end
for i = 1, #elementsToCheck do
for
, element in ipairs(elementsToCheck[i]) do
if (not isElementLocal(element)) and (not isElementFrozen(element)) then -- Only synced objects that can sunk
if isElementInWater(element) and (not getElementData(element, "alreadySunk")) then
-- If it's not already in water, trigger the event
triggerEvent("onClientElementContactWater", element)
setElementData(element, "alreadySunk", true, false)
elseif (not isElementInWater(element)) and getElementData(element, "alreadySunk") then
-- The element moved out of the water. We could trigger a event here
setElementData(element, "alreadySunk", false, false)
end
end
end
end
end
addEventHander("onClientPreRender", root, checkWaterStatus, true, "low-9999")

However, it's a bit inefficient and not very accurate. I did not use testLineAgainstWater to speed up the function a bit.

XManing

2014-08-13 09:56

viewer   ~~0021757

When the function is implemented and inserted in MTA!
Per addEventHander ("onClientPreRender") it is eating to resources
and are too many errors.

Lex128

2016-07-10 06:36

reporter   ~~0024917

AlexTMjugador, you counted the cost performance on this code?
Each frame taking getElementsByType in loop through several types, you re crazy X_x
And wrote an incorrect code, which did not try...

MTA when synchronization peds, players, vehicles changes the state "SetInWater", and here can be called this new event (client and server)

AlexTMjugador

2016-07-10 12:48

viewer   ~~0024920

I know that workaround is not so efficient, and I said so in the previous note. Anyway, look at the last argument in getElementsByType: it is true, so that means that only streamed in elements are taken into account, which should help reduce CPU time usage of the whole loop greatly. About the incorrect code thing, you may be right, I didn't test it, but anyway a bugtracker is not a place where I would expect to find code that can be copied & pasted for practical use on a server. My intention was solely to point to the fact that this request is already possible in Lua, although I agree that a MTA: SA event would be certainly more efficient.

einheit-101

2016-07-10 15:01

reporter   ~~0024921

You really need to have an ancient Pentium III CPU if that tiny bit of code causes a performance loss of more than 0,1 fps

I do a lot more than this onClientPreRender and havent seen any performance issue so far.

AlexTMjugador

2016-07-10 15:24

viewer   ~~0024922

Last edited: 2016-07-10 15:26

View 2 revisions

Now that I think about it, a more efficient approach currently possible in Lua would be to use the onElementStart/StopSync events and let only the syncer client trigger the event on the (hopefully few) elements he syncs. The result would be almost the same and in case of lots of elements streamed in it won't consume as much performance. But that has a major drawback: as objects aren't synced like vehicles, players or peds are, we would have to fallback to the onClientPreRender loop to detect if they sink or not.

Issue History

Date Modified Username Field Change