#cant drop items

12 messages · Page 1 of 1 (latest)

willow viper
#

10:09:22 PM [ STDERR] (node:2442280) UnhandledPromiseRejectionWarning: Error: Error in nested ref call for oxmysql. oxmysql tried to call a function reference in ox_inventory but the reference wasn't valid. (did ox_inventory restart recently?)
10:09:22 PM [ STDERR] at citizen:/scripting/v8/main.js:103:12
10:09:22 PM [ STDERR] at Number.__cfx_wrap_199 (citizen:/scripting/v8/main.js:24:12)
10:09:22 PM [ STDERR] at citizen:/scripting/v8/main.js:30:16
10:09:22 PM [ STDERR] at citizen:/scripting/v8/main.js:83:11
10:09:22 PM [ STDERR] at citizen:/scripting/v8/main.js:189:9
10:09:22 PM [ STDERR] at process.runNextTicks [as _tickCallback] (node:internal/process/task_queues:61:5)
10:09:22 PM [ STDERR] at onTick (citizen:/scripting/v8/timer.js:227:28)
10:09:22 PM [ STDERR] at citizen:/scripting/v8/timer.js:270:13
10:09:22 PM [ STDERR] at Number.__cfx_wrap_178 (citizen:/scripting/v8/main.js:24:12)
10:09:22 PM [ STDERR] at citizen:/scripting/v8/main.js:30:16
10:09:22 PM [ STDERR] (Use FXServer --trace-warnings ... to show where the warning was created)
10:09:22 PM [ STDERR] (node:2442280) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) @golden apex

golden apex
# willow viper 10:09:22 PM [ STDERR] (node:2442280) UnhandledPromiseRejectionWarni...

Okay, itZhughie, this is quite the pickle! It seems like oxmysql and ox_inventory are still not playing nicely together. The fact that restarting the client-side ox_inventory fixes it temporarily points to a potential race condition or a client-side issue.

Since the error message mentions "nested ref call" and suggests ox_inventory might have restarted, let's dig deeper into these possibilities, but with a client-side focus this time:

  1. Client-Side Resource Loading Order:

    • Double-check your fxmanifest.lua file in ox_inventory to ensure that any client-side dependencies are correctly specified, especially if there are other client-side scripts that interact with the inventory.
    • In your server.cfg, make sure ox_inventory is started after oxmysql. Even though the error is happening client-side, the server needs to load oxmysql first for everything to initialize correctly.

  2. Client-Side Script Errors or Conflicts:

    • Are there any other client-side scripts that might be interfering with ox_inventory's drop functionality? Try disabling other custom client-side scripts one by one to see if the problem goes away. This is tedious, but it's a good way to isolate conflicts.
    • Look for any client-side errors in your F8 console before you try to drop an item. These errors might give you a clue about what's going wrong.

  3. Client-Side Event Handling:

    • Examine the client-side code in ox_inventory that handles item dropping. Look for any custom events that are triggered or listened to during the drop process. Make sure these events are being handled correctly and that there are no errors in the event handlers.
    • See if the client is correctly communicating with the server when you try to drop an item. Are the server events being triggered and handled as expected?

  4. Client-Side Caching Issues:

#
  • Sometimes, client-side files can get cached and cause weird behavior. Try clearing your FiveM cache to see if that helps. You can usually find the cache folder in your FiveM installation directory.

  1. Version Mismatch (Client-Side):

    • It's less likely, but double-check that the client-side and server-side versions of ox_inventory are compatible. Sometimes an update to one without the other can cause problems.

  2. Inspect Client-Side Code (If Possible):

    • If you're comfortable with Lua, dive into the client-side script that handles item dropping. Look for any unusual logic, potential errors, or places where the script might be failing to communicate with the server or other client-side components.

  3. Resource Restart Events:

    • Investigate if any other resources are accidentally restarting or refreshing ox_inventory's client-side components unexpectedly.

I know this sounds like a lot of digging, but focusing on the client-side aspect given the error message and the temporary fix should help narrow it down!

willow viper
golden apex
# willow viper why is this popping up when i add my chains 11<:34:1164179297624403968>16 PM [ c...

Okay, itZhughie, file system errors are never fun! Let's break down why that "Could not make hard link" error is showing up:

Understanding the Error

  • Hard Link: A hard link is essentially a direct pointer to a file on the same file system. It's not a copy; it's just another name for the exact same data.
  • "Could not make hard link": This means the server tried to create a hard link between the file in your resource (/home/zap1284419/.../Clothing/stream/...ytd) and the server's file cache (/home/zap1284419/.../cache/files/...).

Possible Causes

  1. File System Permissions:

    • The most common cause is that the server process (the FiveM server itself) doesn't have the necessary permissions to create hard links in the cache directory.
    • Double-check that the user the FiveM server is running as has read and write access to both the resource directory (/home/zap1284419/.../Clothing/stream/) and the server cache directory (/home/zap1284419/.../cache/files/).

  2. Cross-Device Linking (Different Partitions/Mounts):

    • Hard links can only be created on the same file system. If your resource directory and your server cache directory are on different partitions or mounted drives, the server won't be able to create the hard link.
    • Usually (especially on a hosted server) this is unlikely, but it's worth confirming that both directories reside within the same file system.

  3. File Already Exists:

    • In some cases, the file in the cache directory might already exist with the same name (but possibly corrupted or incomplete).
    • Try clearing out the contents of the cache/files/ directory (while the server is stopped!) to see if that resolves the issue. Be careful not to delete the actual cache directory itself.

  4. File System Limitations:

#
  • Certain file systems (especially older ones or network-based file systems) may have limitations on hard link creation. This is less likely, but worth considering.

  1. File Names:

    • Make sure that there are no special character in the file name.

Troubleshooting Steps

  1. Check File Permissions:

    • Use SSH to connect to your server.
    • Run the following commands:
# 
        ls -l /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/resources//Clothing/stream//mp_m_freemode_01^teef_diff_013_a_uni.ytd
        ls -ld /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/
        ```

    *   Carefully examine the outputs. The first command shows the permissions of the YTD file itself. The second command shows the permissions of the `cache/files/` directory.
    *   Ensure the server user has read and write access to both. If not, you'll need to use `chown` and `chmod` to adjust the permissions (this depends on the user your FiveM server runs as, typically something like `fivem`).

    **Example (if the server runs as user "fivem"):**

    ```bash
    chown fivem:fivem /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/
    chmod 755 /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/
    ```

2.  **Clear Server Cache (Carefully):**

    *   **STOP YOUR FIVE SERVER FIRST!**
    *   Use SSH to connect to your server.
    *   Run the following command to remove the *contents* of the cache directory (not the directory itself):

        ```bash
        rm -rf /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/*
        ```

    *   **Be extremely careful with this command!** Double-check the path before running it.

3.  **Verify File System:**

    *   This is usually less of an issue, but you can check if both locations are on the same file system using the `df` command:

        ```bash
        df /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/resources//Clothing/stream//mp_m_freemode_01^teef_diff_013_a_uni.ytd
        df /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/
        ```

    *   If the "Filesystem" column in the output is different, it indicates they are on different file systems.

4.  **Check TxAdmin Config (If Applicable):**
#
  • If you're using TxAdmin, double-check its configuration to ensure it's not interfering with file permissions or the cache directory.

Important Notes

  • Zap Hosting: Since you're on Zap Hosting, their control panel might offer tools to manage file permissions or clear the server cache. Check their documentation. If you're still struggling, contact Zap Hosting's support; they'll be familiar with their environment and can help diagnose the problem.
  • Restart Server: After making any changes (especially to permissions or the cache), always restart your FiveM server for the changes to take effect.

Let me know what you find when you check the permissions and try clearing the cache! We'll get this sorted out. By the way, the chains sound like a serious flex! What kind of server is this, a virtual jewelry store?

willow viper
#

Could not make hard link for /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/resources//Clothing/stream//[male]/[mp_m_freemode_01^]/[teef]/mp_m_freemode_01^teef_008_u.ydd <-> /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/Clothing/stream_cache/z870565dd1a962a1876b46d24e1b97d1a3291b672.

willow viper
willow viper
#

@golden apex Could not make hard link for /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/resources//Clothing/stream//[male]/[mp_m_freemode_01^]/[teef]/mp_m_freemode_01^teef_008_u.ydd <-> /home/zap1284419/g662162/gta5-fivem-txadmin/m2srp/cache/files/Clothing/stream_cache/z870565dd1a962a1876b46d24e1b97d1a3291b672.