fix(esx_mechanicjob): only report a deposit that happened - #132
Open
seltonmt012 wants to merge 1 commit into
Open
fix(esx_mechanicjob): only report a deposit that happened#132seltonmt012 wants to merge 1 commit into
seltonmt012 wants to merge 1 commit into
Conversation
putStockItems showed have_deposited outside the branch that moves the items. Depositing more than you carry printed "invalid quantity" and then told you the amount had been deposited, while nothing left the inventory. The count itself was never checked either, so a zero or negative amount reached the core, where removeInventoryItem raises on anything below one. getStockItem in the same file already has the intended shape: guard the count, report inside the branch. Measured against the shipped handler, a deposit of 50 with 10 carried now stops at "invalid quantity", and 0 and -5 no longer raise. The success path is unchanged.
seltonmt012
force-pushed
the
fix/mechanicjob-deposit-notification
branch
from
August 8, 2026 18:25
1110853 to
c50419b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
putStockItemstells the player the items were deposited even when they were not, and it never checks the amount it was handed.Motivation
Two problems in the same handler.
The
have_depositednotification sits outside the branch that moves the items. Depositing more than you carry prints "invalid quantity" and then, in the same breath, "you have deposited 50 Fix Tool" while the inventory is untouched. The player sees a contradiction and has to open the stock list to find out what really happened.The guard itself is
item.count >= 0, which reads the society stock. A shared stock cannot go below zero, so the condition is always true and checks nothing. The amount the player sent is never validated, so a zero or negative count walks straight intoxPlayer.removeInventoryItem, where the core raisesTried remove a Invalid count. The handler dies there with a Lua error in the console instead of telling the player anything.Implementation Details
getStockItem, 30 lines above in the same file, already has the shape this one is missing: guard the count withcount > 0, and put the message inside the branch that did the work. This change makesputStockItemsmatch it.The useless
item.count >= 0is replaced bycount > 0, not added on top of it, because the society stock check never did anything.I drove the shipped handler against stubs, with the core's
removeInventoryItembehaviour reproduced (it raises below one). Player starts with 10, society with 4:have_deposited(5)invalid_quantityandhave_deposited(50), nothing bookedinvalid_quantityonlyTried remove a Invalid count -> 0invalid_quantityTried remove a Invalid count -> -5invalid_quantityNothing that worked before behaves differently. The two cases that changed were a console error and a false notification.
Usage Example
PR Checklist
Tested headless against the shipped file, not with two clients on a live server.