Jump to content

Kayl

Members
  • Posts

    70
  • Joined

  • Last visited

Everything posted by Kayl

  1. First of all, I'm sorry if this was already discussed but doing a quick search I didn't find anything relevant either on the forum or mantis. I am doing some tests with trucks and trailers and I have noticed the following: - Case 1: + 2 players next to each other + Player A creates a truck & a trailer (either from script or using F1, which is, well, an other script ) + Player A attaches the cab to the trailer + Player B can see all of it happening and sees the trailer moving - Case 2: + 2 players far from each other + Player A creates a truck & a trailer (either from script or using F1, which is, well, an other script ) + Player A attaches the cab to the trailer + Player A drives all the way to Player B + Player B sees Player A's truck but not the trailer + Player B warps elsewhere and back near Player A > still no trailer + Player B warps to the vicinity of where the trailer was created > no trailer there there BUT (see next point) + Player B warps back to Player A, and here only, the trailer appears and is towed. Is it a known issue? Is there any known workaround for that? If it's not, I'll create a bug report but I first wanted to discuss it here. Thank you in advance for your ideas & suggestions. (Note: server & 2 clients: 1.0.3 windows)
  2. First of all, I'm sorry if this was already discussed but doing a quick search I didn't find anything relevant either on the forum or mantis. I am doing some tests with trucks and trailers and I have noticed the following: - Case 1: + 2 players next to each other + Player A creates a truck & a trailer (either from script or using F1, which is, well, an other script ) + Player A attaches the cab to the trailer + Player B can see all of it happening and sees the trailer moving - Case 2: + 2 players far from each other + Player A creates a truck & a trailer (either from script or using F1, which is, well, an other script ) + Player A attaches the cab to the trailer + Player A drives all the way to Player B + Player B sees Player A's truck but not the trailer + Player B warps elsewhere and back near Player A > still no trailer + Player B warps to the vicinity of where the trailer was created > no trailer there there BUT (see next point) + Player B warps back to Player A, and here only, the trailer appears and is towed. Is it a known issue? Is there any known workaround for that? If it's not, I'll create a bug report but I first wanted to discuss it here. Thank you in advance for your ideas & suggestions. (Note: server & 2 clients: 1.0.3 windows)
  3. Kayl

    Hide Player Map

    I agree with what has been said above. Because indeed there are two concepts here that were not well explicit while using forcePlayerMap: we have the concept of visibility and the concept of forcing. From what you guys said and what I think, either we can have: 1. setPlayerMapShowing(bool bShowing) a. In this scenario, forcing on would require: setPlayerMapShowing(true) + toggleControl("radar",false) b. Forcing off would require: setPlayerMapShowing(false) + toggleControl("radar",false) c. And stop forcing would simply require: toggleControl("radar",true) 2. setPlayerMapShowing(bool bShowing,[ bool bForced = false]) a. Forcing on: setPlayerMapShowing(true, true) (player can't use F11, whatever the state of the actual "radar" control) b. Forcing off: setPlayerMapShowing(false, true) (player can't use F11, whatever the state of the actual "radar" control) c. Simply showing it: setPlayerMapShowing(true) (player can use F11 however to hide it if they want) d. Simply hiding it: setPlayerMapShowing(false) (player can use F11 however to show it if they want) In both scenarios, it seems that forcePlayerMap would become deprecated but its implementation could be changed for it to produce the exact same result as it does know (whether we like the current implementation or not) with the following internal calls: If scenario 1: forcePlayerMap(true) = setPlayerMapShowing(true) + toggleControl("radar",false) forcePlayerMap(false) = toggleControl("radar",true) If scenario 2: forcePlayerMap(true) = setPlayerMapShowing(true, true) forcePlayerMap(false) = setPlayerMapShowing(isPlayerMapVisible(), false) As for the isPlayerMapShowing I don't think it is necessary, given we already have isPlayerMapVisible and isPlayerMapForced. And as for the name of setPlayerMapShowing, actually since we have isPlayerMapVisible it could be setPlayerMapVisible (whatever the scenario chosen)
  4. Kayl

    Hide Player Map

    I agree with what has been said above. Because indeed there are two concepts here that were not well explicit while using forcePlayerMap: we have the concept of visibility and the concept of forcing. From what you guys said and what I think, either we can have: 1. setPlayerMapShowing(bool bShowing) a. In this scenario, forcing on would require: setPlayerMapShowing(true) + toggleControl("radar",false) b. Forcing off would require: setPlayerMapShowing(false) + toggleControl("radar",false) c. And stop forcing would simply require: toggleControl("radar",true) 2. setPlayerMapShowing(bool bShowing,[ bool bForced = false]) a. Forcing on: setPlayerMapShowing(true, true) (player can't use F11, whatever the state of the actual "radar" control) b. Forcing off: setPlayerMapShowing(false, true) (player can't use F11, whatever the state of the actual "radar" control) c. Simply showing it: setPlayerMapShowing(true) (player can use F11 however to hide it if they want) d. Simply hiding it: setPlayerMapShowing(false) (player can use F11 however to show it if they want) In both scenarios, it seems that forcePlayerMap would become deprecated but its implementation could be changed for it to produce the exact same result as it does know (whether we like the current implementation or not) with the following internal calls: If scenario 1: forcePlayerMap(true) = setPlayerMapShowing(true) + toggleControl("radar",false) forcePlayerMap(false) = toggleControl("radar",true) If scenario 2: forcePlayerMap(true) = setPlayerMapShowing(true, true) forcePlayerMap(false) = setPlayerMapShowing(isPlayerMapVisible(), false) As for the isPlayerMapShowing I don't think it is necessary, given we already have isPlayerMapVisible and isPlayerMapForced. And as for the name of setPlayerMapShowing, actually since we have isPlayerMapVisible it could be setPlayerMapVisible (whatever the scenario chosen)
  5. Kayl

    Hide Player Map

    I guess you are right. I would like the confirmation from a MTA dev member that indeed forcePlayerMap( player, false ) is supposed to hide the map however it was opened. Shall I create a bug report about that?
  6. Kayl

    Hide Player Map

    I guess you are right. I would like the confirmation from a MTA dev member that indeed forcePlayerMap( player, false ) is supposed to hide the map however it was opened. Shall I create a bug report about that?
  7. Kayl

    Hide Player Map

    Thanks for the ideas. Below you'll find the code of what I have tried so far. + forcePlayerMap(player,false) seems to hide the map only if it was shown due to a previous forcePlayerMap(player,true), it doesn't work if it was shown with F11 + the "radar" command works when typed in F8 but I can't seem to make it work from code + setting the control state of the radar "control" doesn't seem to work Server test: function testserver(player,cmd,id) local test_id = tonumber(id) if test_id == 1 then --show & hide > works forcePlayerMap(player,true) setTimer(forcePlayerMap,5000,1,player,false) elseif test_id == 2 then --try to see if the "radar" input can show the map setControlState(player,"radar",true) setTimer(setControlState,1000,1,player,"radar",false) setTimer(forcePlayerMap,5000,1,player,false) elseif test_id == 3 then --try to see if the "radar" command can be called executeCommandHandler("radar",player) setTimer(forcePlayerMap,1000,1,player,false) elseif test_id == 4 then --gives 5 seconds for player to show map and then try to hide it setTimer(forcePlayerMap,5000,1,player,false) elseif test_id == 5 then --gives 5 seconds for player to show map and then try to hide it with input setTimer(setControlState,5000,1,player,"radar",true) setTimer(setControlState,6000,1,player,"radar",false) elseif test_id == 6 then --gives 5 seconds for player to show map and then try to hide it with force on & off setTimer(forcePlayerMap,5000,1,player,true) setTimer(forcePlayerMap,5500,1,player,false) else outputChatBox("No test executed") end end addCommandHandler("stest",testserver) Client test: function testclient(cmd,id) local test_id = tonumber(id) if test_id == 1 then setControlState("radar",true) setTimer(setControlState,1000,1,"radar",false) elseif test_id == 2 then executeCommandHandler("radar") elseif test_id == 3 then --gives 5 seconds to enable map and try to hide it with input setTimer(setControlState,5000,1,"radar",true) setTimer(setControlState,5500,1,"radar",false) else outputChatBox("No test executed") end end addCommandHandler("ctest",testclient)
  8. Kayl

    Hide Player Map

    Thanks for the ideas. Below you'll find the code of what I have tried so far. + forcePlayerMap(player,false) seems to hide the map only if it was shown due to a previous forcePlayerMap(player,true), it doesn't work if it was shown with F11 + the "radar" command works when typed in F8 but I can't seem to make it work from code + setting the control state of the radar "control" doesn't seem to work Server test: function testserver(player,cmd,id) local test_id = tonumber(id) if test_id == 1 then --show & hide > works forcePlayerMap(player,true) setTimer(forcePlayerMap,5000,1,player,false) elseif test_id == 2 then --try to see if the "radar" input can show the map setControlState(player,"radar",true) setTimer(setControlState,1000,1,player,"radar",false) setTimer(forcePlayerMap,5000,1,player,false) elseif test_id == 3 then --try to see if the "radar" command can be called executeCommandHandler("radar",player) setTimer(forcePlayerMap,1000,1,player,false) elseif test_id == 4 then --gives 5 seconds for player to show map and then try to hide it setTimer(forcePlayerMap,5000,1,player,false) elseif test_id == 5 then --gives 5 seconds for player to show map and then try to hide it with input setTimer(setControlState,5000,1,player,"radar",true) setTimer(setControlState,6000,1,player,"radar",false) elseif test_id == 6 then --gives 5 seconds for player to show map and then try to hide it with force on & off setTimer(forcePlayerMap,5000,1,player,true) setTimer(forcePlayerMap,5500,1,player,false) else outputChatBox("No test executed") endendaddCommandHandler("stest",testserver) Client test: function testclient(cmd,id) local test_id = tonumber(id) if test_id == 1 then setControlState("radar",true) setTimer(setControlState,1000,1,"radar",false) elseif test_id == 2 then executeCommandHandler("radar") elseif test_id == 3 then --gives 5 seconds to enable map and try to hide it with input setTimer(setControlState,5000,1,"radar",true) setTimer(setControlState,5500,1,"radar",false) else outputChatBox("No test executed") endendaddCommandHandler("ctest",testclient)
  9. Kayl

    Hide Player Map

    Well you got it right. I want to disable the F11 functionality. I can disable the key to avoid the player to show it. But I can not force it off when it is already on, since forcePlayerMap( player, false ) only seem to "stop forcing" but doesn't remove the map if it is shown.
  10. Kayl

    Hide Player Map

    I take the liberty to request fresh ideas again for my problem since it still isn't solve. Once again I'm not talking about the HUD radar but the map that can be forced on with forcePlayerMap but can not be forced off (at least I don't know how, hence the topic).
  11. I don't know if this helps but after I get this download error in MTA (windows client 1.0.3) all my HTTP connexions timeout (firefox, MTA server list). This is a nasty bug because it has an impact outside MTA. Other connections (attempt to reconnect to server, internet radios) still work fine. It takes like 30 seconds before going back to normal.
  12. I understand Antibird. It was only identical in that, without a setElementSyncer function, I need to do the "rapid" sync manually and was also wondering which method to use (event VS data). I tried the event method and that was pretty bad (because I need to dispatch it back). I'll personally (but here, I agree, our two uses of manual sync diverge) wait for the setElementSyncer function to be implemented (since I feel guilty for having created such an amazing server lag yesterday).
  13. Actually I have the same problem as you Antibird. I have several vehicles positions that are changed by ONE player client-side and I need to dispatch this information to all others players (except himself because he needs to keep the "truth" on the elements and can not afford server lag on this). What I have done is, in a 50ms timer, on the driver side, I call a server function (basically event) with the new positions of the desired objects. When the server receives this event, it then dispatches this information to all players except the caller (the server could set the positions of the objects but then the driver's view won't be as smooth). Client side, for all players, when they receive this information from the server they set the position and velocity of the objects accordingly. All that sounds good on paper and indeed works fine with few players, but yesterday when installing this script on a real server, this caused massive lag. The website went down, and it was taking 10 minutes only to join the server. The only way it stopped (before we could join to disable that) was to ask players to stop using this feature. So here again, I'm wondering what would be the best way to sync that kind of data? It seems that if you do clientSide setPosition on elements for which the current player is the "syncer" (ped & vehicle for which they are the driver) then MTA can handle it properly. Would there be a way to set a player as the "syncer" for other elements so the changes done client side are handled by MTA's sync methods?
  14. I couldn't wait to test with players, I downloaded 1.0 client and was able to confirm the bug. With the method of traversing the element tree manually however it works fine and gui elements can be found and hidden correctly. Since it's pretty quick and well targeted, I decided to go for this method even for 1.0.2 players. Thanks for the tip.
  15. Yep that's what I'm currently doing, thx for the reminder though. I'll tell you if it fixed it as soon as I can test it with the "bad" players
  16. Kayl

    Hide Player Map

    I'm sorry but in my initial post I started with: And on the page you provided the only radar mentioned that can be disabled is the bottom left one. So I guess showPlayerHudComponent is not what I'm after. Am i missing an item in showPlayerHudComponent ?
  17. Ok that sounds like a potential fix. I'll call it only when getElementsByType fails (hence only for 1.0 normally). I'll post the results here.
  18. Thanks for the quick reply. However it is called during the mini-game process hence long after the resource was started.
  19. Hello, I have, for a mini-game, a requirement to hide some gui elements, such as buttons and windows. Since those elements belong to the freeroam resource and have known names, it easy to find them and force their visibility to "false" simply by looking at the results of getElementsByType("gui-window") and getElementsByType("gui-button"). However I have noticed that this getElementsByType function, for some players only, doesn't return anything for the aforementioned types. When looking at GetElementsByType we can see that the gui types are not referenced even though they appear in the Element tree. It seems that the players for which it doesn't work are running the 1.0 version whereas those for which it works have 1.0.2. Is there a documented change that explains why GetElementsByType now works with the GUI types, and is there a way to make it work for 1.0 or should I just prevent the access to this minigame for 1.0 users? Thanks.
  20. Kayl

    Hide Player Map

    Hello, So first of all I am not talking about the HUD radar in the lower left corner. I am talking about the full size radar map that you can toggle using the "radar" command, bound to the F11 key by default. I am looking for a way to hide this radar map for specific players. I know there is a server side function forcePlayerMap. However it seems to force or stop forcing the display of the map. It can not force the radar map "off". On the client side there are isPlayerMapForced and isPlayerMapVisible, only getters, no setters. I tried: toggleControl("radar",false"): it only affects the availability of the "radar" command, it doesn't change the current state setControlState("radar",true): when isPlayerMapVisible() return true to try to hide it, doesn't work executeCommandHandler("radar"): this returns false so I guess it's not possible. If it was that easy I guess the forcePlayerMap function wouldn't exist I'm out of ideas. Is there any undocumented function that would to the job or am I misusing one of the aforementioned techniques?
×
×
  • Create New...