IIYAMA

Be more specific. What is the result? Also debug the newly added style DOM element: https://wiki.multitheftauto.com/wiki/ToggleBrowserDevTools

executeBrowserJavascript ( webBrowser, [[document.getElementsByTagName('html')[0].innerHTML += "<style>html {position:absolute; width: ]] .. (x * ancho) .. [[px; height:]] .. (y * alto) .. [[px; left: 50%; top: 50%; transform: translate(-50%, -50%); }</style>" ]] ) *

local webBrowser = createBrowser(sx, sy, false, true) -- + enable transparent executeBrowserJavascript ( webBrowser, [[document.getElementsByTagName('html').innerHTML += "<style>html {position:absolute; width: ]] .. x*ancho .. [[px; height:]] ..y*alto .. [[px; left: 50%; top: 50%; transform: translate(-50%, -50%); }</style>" ]] ) You might can solve it this way. Untested. @aka Blue

You could load a small xml file on to the client his computer. (The whole time) When the player reconnects, subtract the ammo that hasn't been synced. (Sync once in a while with the server) Ofcourse add a security layer. Which will prevent players to edit those values. If the file has a mismatch with the account data of the player. Make sure to punish him by deleting all the ammo. Why xml and not a default file? Because you can edit parts of it. And not have to recreating the whole file when there are changes. (And yes for the XML haters, you can also use JSON in XML... cry!)

So what did you do? Else use just a dirty timer or create it clientside.

It might be possible that either by default or by another script the control is enabled. I recommend to use event "onPlayerSpawn" + Put the addEventHandler priority to low. (which is for the onPlayerSpawn event) This will make sure that the control settings are not being overwritten by anything else at serverside.

@jakson did you use this function after the event "onPlayerSpawn"?

https://wiki.multitheftauto.com/wiki/FocusBrowser @aka Blue

What is your ultimate goal? Being able to use m4 and ak47 within the same inventory? In that case you could give just 999999 ammo per weapon. When the table runs out of ammo clientside. Block the shooting button of that weapon. And send a signal to serverside that the weapon is empty. Don't be me, with complex :~ that eats too much network.

RPG counts as weapon that fires bullets. It triggers the event atleast at clientside. Not sure if it also triggers serverside. If not, then trigger the event manually. (It is not as if you can fire a RPG rapidly.) About triggering client to server every time a player shoots. This was a part of something I build a long time ago. It was a script that would sending bullet lines over to serverside. And detect if it hit players. More or less how modern games do their damage model. That is for the onces that actually do the detection serverside. But the issue with that was that it strongly relied on fast internet. If this criteria was not met, I was forced to freeze those players(high packet loss) and that made it even more unplayable for those. (onPlayerWeaponFire was not available yet) If those players where not frozen, they would teleport around everytime they shot a few bullets. TriggerServerEvent's are using TCP. Which is not streaming. Only 1 message can be send and received at the sametime. + causing the network to be blocked all the time. Sending Message from client to server Server receives Server sends a message back.(message: yes it has been delivered) Client sends next message to the server. Well that was my issue/story. My advice: Fake the hud information. Do only sync when it is absolutely necessary.

I am not 100% sure why sending the root to the other side will create more CPU usage. It is not logic when you look at the element tree Element_tree. Most addEventHandlers have by default propagation enabled. Which means that all element (children) in the server will be able to trigger those addEventHandlers, if the eventname is the same and the handler element is root. The situation with using a child should be able to trigger more events than when the root element is used. What is the difference between sending root and resourceRoot from a performance perspective? Can't answer that. Not even sure if it has any relations with the addEventHandler.?

yes, this is how it should be done. for which function? triggerServer/ClientEvent, addEventHandler or getElementsByType?

The browser is a very different interface, but is facing the exact same issues. Checkbox, radio buttons = last incoming message wins After every change, you should use an increased int value to make sure that very old messages are not valid. This can also be done with timestamp. Luckily tcp is used, else it will be a really mess with the messages order. Text / label = claiming the focus right. The first player can edit. The other players do have disabled inputs and even get kicked out of the field (which is reset to the last known server value). And yes blocking messages from players that have no focus rights. An enchantment on to text/labels is: - Updating the text while typing. - Showing who is editing.

@majqq The basic The most safest way is like php does it. Sending an instruction to serverside. Serverside updates the list and send it back. During the proces the browser is refreshing the page, which is more or less freezing the interface. This instruction is not the whole list of items. But it contains the identifiers of the items that are going to change + how they are going to change. Enchantments It is not idealistic to freeze the interface. In case of multiple users editing the same data. If your players have good internet, then you might not even need an enchantment. But be warned, enchantments on top of sync items between server and multiple clients is complex. You can update the clientside data first. Instruction: Item with id 253. Move to index 30. Clientside Do the instruction Send the instruction to serverside Serverside Do the instruction IF successful sync instruction (other clients) ELSE If different outcome (A different client updated something before you did) Resend list to clientside (you) sync instruction (other clients) ELSE Resend list to clientside (you) or undo instruction in case of not making any other changes.

@majqq Scaling over the X axis? We do not play MTA on a smartphone you know? (Yes, we want to) For position? Sure! Scaling? No! The only thing that matters is comparing the same thing with the same thing. Square! That is something we can work with. Out of every MTA screen format we can make the exact same square from the y axis with a different amount of pixels. This is something we can scale up and down! If we are doing that with the X axis, then we are missing some pixels which we can't take in to account and it will look bad. The only things that are going to be different per computer: How sharp things are looking. So it might be handy to scale text down to a limit of 80%. The pixel size of your monitor. (which not even your computer knows)

Did you also try the example on wiki?

The same position + offset. X + 1, Y, Z Or X, Y + 1, Z

@Samking See example on this page: https://wiki.multitheftauto.com/wiki/GetScreenFromWorldPosition

@KeksKing Better to start over. https://github.com/multitheftauto/mtasa-blue/blob/master/Server/mods/deathmatch/acl.xml And just copy the things that you think that are useful in it.

1. You do not have to do anything. Putting them to nil, will indeed clean them, but there is so much RAM to eat. In case of a large dataset, sure nil it. http://lua-users.org/wiki/GarbageCollectionTutorial 2. Everything together. Ai is something heavy in general, so there is nothing to be surprised about. - Functions calls. - Lot of events. - Calculations - Collision detection 3. Yes, serverside only. Easiest method: local API's Don't even think about integrations.

@JKiller55 Take a step back from your calculation. If you want to go complex, sure why not? But first ... Start with something you can work with. local multiplier = hp / 100 -- 0 hp = 0x; 100 hp = 1x local red = 255 * (1 - multiplier) local green = 255 * multiplier

@Dziugasc Indeed, that is not going to work. local skins = {7,124,69} local skinIndex = 1 function getSelectedSkin() local selectedSkin = skins[skinIndex] return selectedSkin end function updateToNextSkin () skinIndex = skinIndex + 1 if skinIndex > #skins then skinIndex = 1 end return getSelectedSkin() end function updateToPreviousSkin () skinIndex = skinIndex - 1 if skinIndex < 1 then skinIndex = #skins end return getSelectedSkin() end

It looks like the database column `pos` isn't correctly set-up. A tool you can use, to view this information, make sure the resource isn't running when you use it: https://github.com/sqlitebrowser/sqlitebrowser

Can you show me the complete JSON string? Because this one looks incomplete. This looks fine: [ <-- MTA wrapper [ [ <-- first array (table) [ [ [ <-- sub array (table) This looks like it is cut off, after getting it from the database (on the end of the string) ], [" Not sure if there is a character limit for the console. A quick validation: debugJSON_A = stringA -- JSON from clientside -- get the string from the database: debugJSON_B = stringB if debugJSON_A != debugJSON_B then outputChatBox("database column `hud` is not correct set-up") end

Because the client hasn't loaded yet. Because the addEventHandler hasn't the right event. Should be "showCharacters" The base Element is incorrect. You sending the parent = root from serverside element to a handler with the child = localPlayer at clientside. root (container) > localPlayer (child) < NOT WORKING localPlayer (child) > root (container) < WORKING (You are sending a triggerClientEvent, without target, so sending it to every player in game.) In case of sending it directly after loading the resource: (best practice) CLIENT addEventHandler("onClientResourceStart", resourceRoot, function () triggerServerEvent("onThisClientResourceStart", resourceRoot) end, false) SERVER local characterName = 'John Doe' addEvent("onThisClientResourceStart", true) addEventHandler("onThisClientResourceStart", resourceRoot, function () -- client is the target (the player that executed the event: onThisClientResourceStart) triggerClientEvent(client, 'showCharacters', resourceRoot, characterName) end, false) CLIENT function showCharacters(characterName) outputChatBox(characterName) -- localPlayer < this is running on the client/player his pc. No need to define the receiver, as only this player can receive the message end addEvent('showCharacters', true) addEventHandler('showCharacters', resourceRoot, showCharacters, false)