i need help with scripting
-
hey guys my mod seatbelt v everytime the player switches the ped-player to another the whole script break i can sent my mod code to anyone who can figure it out {its only about 50 lines)
-
@dani703q Send me the code and I'll see if I can help.
-
@dani703q from what I can understand, you seem to be getting the player's ped handle once and storing/reusing it, and that handle becomes invalid once the player's ped changes (because a new ped is spawned/created, and the old ped is usually generally despawned/destroyed, but if it isn't, then it pertains to the player's old ped and not the player's new ped); you should not store and continue to (re)use handles across more than a single tick or frame without some kind of validation.
-
@JayMontana36 I think you're bang on. I change my player model with LemonUI menus I wrote and after doing so need to refresh to allow certain functions, such as spawning vehicles, to refer to current player rather than previous player. Spawned companions don't seem to mind however, they will follow new player too.
Never tried to resolve this because refreshing is so easy (insert or F11 in my bindings) but if you have C# solution would love if you shared it.
-
@JohnFromGWN I have solutions (and examples) for Lua but none for C# (besides saying something along the lines of "convert to or write the equivalent for your language and development environment").
you seem to be getting the player's ped handle once and storing/reusing it
The very basic (and very simple) solution pretty much would be to just not do this, and instead just use the "
PlayerPedId" game native at the beginning of the thread/draw, instead of using your cached/stored from before. Like, rather than getting the player'd ped handle (only once and storing/reusing it across several frames/ticks) whenever you open the menu, instead get it when you select an option that actually needs or utilizes it; alternatively, you can also just, anywhere in the beginning of the thread/loop, update the player ped variable, before it is used or needed later on.Example A in Lua:
JM36.CreateThread(function() while true do --[[ PlayerPedId() AKA PLAYER.PLAYER_PED_ID() - Get the latest player ped handle in the beginning by asking the game (native) ]] local PlayersPedHandle = PlayerPedId() -- Some code and stuff here that makes use of PlayersPedHandle --[[ Wait, or end up with an endless loop that ends your gaming session ]] JM36.Wait() end end)Example B in Lua:
JM36.CreateThread(function() --[[ Faster access to cached Player Information which gets updated before this thread runs and is always up to date no matter where you use it ]] local PlayerInfo = Info.Players while true do --[[ Get the latest player ped handle from the updated cache in the beginning instead of asking the game or reusing an old ]] local PlayersPedHandle = PlayerInfo.Handle -- Some code and stuff that makes use of PlayersPedHandle --[[ Wait, or end up with an endless loop that ends your gaming session ]] JM36.Wait() end end)
-
@JayMontana36 thanks, will take a look.
-
@Niziul said in i need help with scripting:
@dani703q Send me the code and I'll see if I can help.
Please share the solution if you can, pretty sure the issue is as described above.
-
Hashes: 0xD80958FC74E988A6 0xFA92E226
Ped PLAYER_PED_ID() // 0xD80958FC74E988A6 0xFA92E226
Returns current player ped
-
@JohnFromGWN said in i need help with scripting:
Please share the solution if you can, pretty sure the issue is as described above.
I didn't understand.
-
Essentially you create a variable for storing the player's ped handle, and you make sure you update it (or keep it updated) prior to utilizing that variable every frame; in Lua, you can create and discard (local) variables in line, which is slightly faster than predefining the variable and updating it later.
Side note is that you could also just do what I see plenty of people doing and not caching/storing the player's ped handle at all, and instead simply just opting to call/ask the rage native each time (or in each place) where you need the player's ped handle, which is also what official R* scripts do (based upon decompiled scripts) anyways.
-
@Niziul you offered OP to send you his code. If he did, and if you solved the issue, could you please share your code solution here in this thread. Thanks.
-
@JayMontana36 I'm not a programmer but I follow what you're suggesting.
Declare variable to store id, in essence caching it
Get current player ID and store it
Check with on tick for player model changes
If player (player model) changed, then update variable
New ped player is now assigned the new ped idTrick is to use ped id, not ped player which gets wiped when you change model.
Simple logic but will need some trial and error.
-
Check with on tick for player model changes
If player (player model) changed, then update variableNo actually, that's just extra (wasted) CPU cycles for no reason, and also wouldn't work if the player (re)spawns a new ped using the same old model; you just have to pretty much keep calling/asking that native for the player's ped handle at least once for every frame that you need/intend to use the handle in. You could do validation checks like I had previously mentioned, but meh, same thing about extra/wasted CPU cycles.
-
I thought about that, wasted cycles due to on tick. Having said, I have many ontick events and there is definitely no lag, no performance hit - it depends entirely on what the functions are doing. Checking for a player id should not be not cpu intensive.
If in the OP the issue is only the seatbelt, then you check the player id before and after. Period.
no?
-
@JohnFromGWN said in i need help with scripting:
I thought about that, wasted cycles due to on tick. Having said, I have many ontick events and there is definitely no lag, no performance hit - it depends entirely on what the functions are doing. Checking for a player id should not be not cpu intensive.
If in the OP the issue is only the seatbelt, then you check the player id before and after. Period.
no?
Well, it's not that having a bunch of ontick or tick handlers or threads does anything to performance (it doesn't/shouldn't, really it's just something else to do or execute next before advancing to the next frame), it's just the part where you stated checking if the player's model (hash) changed that's a waste of cpu cycles, especially since say someone spawns a multiplayer ped (model), and then they respawn that same exact multiplayer ped (model), you would basically not be able to know or detect that the player's ped's handle is different because the models are the same (hash), thus such a script would believe that all is fine and normal when it's not (and the handle is invalid). You also would have to be feeding the natives with an entity script handle anyways, when overall the solution is even easier/simpler: only use/ask one game native (
PlayerPedId) for the player's ped handle when/where you need it (or per frame before anything else that depends on it), and don't worry about checking anything else like what entity model (hash) they are or anything like that, and you should pretty much never run into any problems or anything with invalid handles.
-
@JohnFromGWN said in i need help with scripting:
Ped PLAYER_PED_ID() // 0xD80958FC74E988A6 0xFA92E226
-
@dani703q sorry not sure what your post means. Is this your code WIP or did you solve the issue. I skimmed quickly through your code and couldn't find a reference to switching players so I'm guessing you haven't found a solution?
I have a similar issue but realized it's way too complicated because it occurs between scripts, not within script.
-
- list item