• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

TFS 1.4.2 onMoveItem does not react?

Marko999x

Marko999x

999x era
Premium User
Joined
Dec 14, 2017
Messages
2,864
Solutions
82
Reaction score
1,967
Location
Germany
For some reason item can still be moved, idk why.
It worked perfect on TFS 1.5 while TFS 1.4.2 react weird.
Maybe you guys can see the problem here :D

Lua: 
local ids = {9999, 6000}

local ec = EventCallback

ec.onMoveItem = function(self, item, count, fromPosition, toPosition, fromCylinder, toCylinder)
    if table.contains(ids, item:getActionId()) and toPosition.x ~= CONTAINER_POSITION then
        self:sendTextMessage(MESSAGE_INFO_DESCR, 'This item can not be moved.')
        return RETURNVALUE_NOTPOSSIBLE
    end
    return RETURNVALUE_NOERROR

end
ec:register()
 
Last edited:
Sort by date Sort by votes
Evil Hero said:
You probably want to check if all of those commits Build software better, together (https://github.com/search?q=repo%3Aotland%2Fforgottenserver+eventcallback&type=commits) are also applied to 1.4.2, if not then this could be the case why this works on master but not on older versions
Click to expand...
According to that list there were no changes to eventcallback since 1.4.2 to 1.5, except changes in lua files that were really just syntactical sugar where sarah changed some things like so

Lua: 
if EventCallback.onChangeMount then
        if not EventCallback.onChangeMount(self, outfit.lookMount) then

////changed to

local onChangeMount = EventCallback.onChangeMount
    if onChangeMount then
        if not onChangeMount(self, outfit.lookMount) then

/// and so on and so forth.

Other than those lua changes, nothing else on the list has been done since 1.4.2.
I feel like the original poster (not the one on this thread), over looked the registration error (having ec:register() inside function), and every other error as well have all been explained already... I don't think there is an issue with 1.4.2 itself, or its source code, however I could be wrong. If someone posts here and says that I am wrong, that they the event is definitely broken in vanilla 1.4.2 I will dig deeper until I have found a solution, but for now, I chalk it all up as user error.
 
Upvote 0 Downvote
Codinablack said:
According to that list there were no changes to eventcallback since 1.4.2 to 1.5, except changes in lua files that were really just syntactical sugar where sarah changed some things like so

Lua: 
if EventCallback.onChangeMount then
        if not EventCallback.onChangeMount(self, outfit.lookMount) then

////changed to

local onChangeMount = EventCallback.onChangeMount
    if onChangeMount then
        if not onChangeMount(self, outfit.lookMount) then

/// and so on and so forth.

Other than those lua changes, nothing else on the list has been done since 1.4.2.
I feel like the original poster (not the one on this thread), over looked the registration error (having ec:register() inside function), and every other error as well have all been explained already... I don't think there is an issue with 1.4.2 itself, or its source code, however I could be wrong. If someone posts here and says that I am wrong, that they the event is definitely broken in vanilla 1.4.2 I will dig deeper until I have found a solution, but for now, I chalk it all up as user error.
Click to expand...
fwiw, I had problems with it as well.

I think I had to add incrementing numbers, so it would work on all the different scripts, otherwise weirdshit™ would happen.

Lua: 
ec:register(1)
ec:register(2)
ec:register(3) -- different number in each script
ec:register(4)
 
Upvote 0 Downvote
The last callback registered holds the return value. That means if you have 10 callbacks, on 9 of these callbacks the return value wouldn't matter except for the the last one (callback id: 10), obviously the order matters.
 
Upvote 0 Downvote
Roddet said:
The last callback registered holds the return value. That means if you have 10 callbacks, on 9 of these callbacks the return value wouldn't matter except for the the last one (callback id: 10), obviously the order matters.
Click to expand...
Am I reading this wrong, or are you saying that with my above method.. no matter what I return in the first 9 scripts, it'd still trigger the 10th script?

ah w/e. xD
I don't have it in me to test that theory. lmao
 
Upvote 0 Downvote
Codinablack said:
According to that list there were no changes to eventcallback since 1.4.2 to 1.5, except changes in lua files that were really just syntactical sugar where sarah changed some things like so

Lua: 
if EventCallback.onChangeMount then
        if not EventCallback.onChangeMount(self, outfit.lookMount) then

////changed to

local onChangeMount = EventCallback.onChangeMount
    if onChangeMount then
        if not onChangeMount(self, outfit.lookMount) then

/// and so on and so forth.

Other than those lua changes, nothing else on the list has been done since 1.4.2.
I feel like the original poster (not the one on this thread), over looked the registration error (having ec:register() inside function), and every other error as well have all been explained already... I don't think there is an issue with 1.4.2 itself, or its source code, however I could be wrong. If someone posts here and says that I am wrong, that they the event is definitely broken in vanilla 1.4.2 I will dig deeper until I have found a solution, but for now, I chalk it all up as user error.
Click to expand...

C++: 
local ids = {9999, 6000}

local ec = EventCallback

ec.onMoveItem = function(self, item, count, fromPosition, toPosition, fromCylinder, toCylinder)
    print("Item move event triggered!") -- Print a message to indicate the event is triggered
    print("Item ID:", item:getId()) -- Print the item ID for debugging
    print("Destination position:", toPosition.x, toPosition.y, toPosition.z) -- Print the destination position for debugging
    if table.contains(ids, item:getActionId()) and toPosition.x ~= CONTAINER_POSITION then
        print("Item cannot be moved:", item:getId()) -- Print an error message for debugging
        self:sendTextMessage(MESSAGE_INFO_DESCR, 'This item can not be moved.')
        return RETURNVALUE_NOTPOSSIBLE
    end
    print("Item moved successfully!") -- Print a message indicating the item is successfully moved
    return RETURNVALUE_NOERROR
end

ec:register()

With these print statements added, you'll be able to track each step of the item movement process and check important information such as the item ID and destination position, along with messages indicating success or potential errors. This should help you debug the code more effectively.
 
Upvote 0 Downvote
Upvote 0 Downvote
Roddet said:
It's more like a fact xD

Here is the fix though (didn't look at the code until now)
github.com

TFS-1.5-Downgrades/data/scripts/lib/event_callbacks.lua at 8.60 · nekiro/TFS-1.5-Downgrades

Alternative forgottenserver versions for older protocols support - nekiro/TFS-1.5-Downgrades
github.com github.com

Just adding EVENT_CALLBACK_ONMOVEITEM should fix the issue, the same applies for TFS 1.4.2
Click to expand...
haha. the tfs 1.4.2 is remarkably different from this code.

But nice to know I wasn't crazy.
It always felt wonky.
 
Upvote 0 Downvote
Xikini said:
Am I reading this wrong, or are you saying that with my above method.. no matter what I return in the first 9 scripts, it'd still trigger the 10th script?

ah w/e. xD
I don't have it in me to test that theory. lmao
Click to expand...
All scripts matter... the one with the lowest index is executed first and the one with the highest index will be the last to be executed, but when any event returns a cancellation value such as false or a value other than a RETURNVALUE_NOERROR, the other ascending events will not be executed

This way of ordering events is very good for several things, for example...
the onDropLoot events, or onGainExperience, ect...
 
Upvote 0 Downvote
Mateus Robeerto said:
local blockedIDs = {9999, 6000} local ec = EventCallback ec.onMoveItem = function(self, item, count, fromPosition, toPosition, fromCylinder, toCylinder) if table.contains(blockedIDs, item:getActionId()) then self:sendTextMessage(MESSAGE_INFO_DESCR, 'This item cannot be moved.') return RETURNVALUE_NOTPOSSIBLE end return RETURNVALUE_NOERROR end ec:register(-11)
Click to expand...

Xikini said:
fwiw, I had problems with it as well.

I think I had to add incrementing numbers, so it would work on all the different scripts, otherwise weirdshit™ would happen.

Lua: 
ec:register(1)
ec:register(2)
ec:register(3) -- different number in each script
ec:register(4)
Click to expand...

Puting 1 as example instead of -1 or -2 or anything else worked :D
 
Upvote 0 Downvote
alexxxxxxx said:
C++: 
local ids = {9999, 6000}

local ec = EventCallback

ec.onMoveItem = function(self, item, count, fromPosition, toPosition, fromCylinder, toCylinder)
    print("Item move event triggered!") -- Print a message to indicate the event is triggered
    print("Item ID:", item:getId()) -- Print the item ID for debugging
    print("Destination position:", toPosition.x, toPosition.y, toPosition.z) -- Print the destination position for debugging
    if table.contains(ids, item:getActionId()) and toPosition.x ~= CONTAINER_POSITION then
        print("Item cannot be moved:", item:getId()) -- Print an error message for debugging
        self:sendTextMessage(MESSAGE_INFO_DESCR, 'This item can not be moved.')
        return RETURNVALUE_NOTPOSSIBLE
    end
    print("Item moved successfully!") -- Print a message indicating the item is successfully moved
    return RETURNVALUE_NOERROR
end

ec:register()

With these print statements added, you'll be able to track each step of the item movement process and check important information such as the item ID and destination position, along with messages indicating success or potential errors. This should help you debug the code more effectively.
Click to expand...
Thanks.... I guess.
See, I wasn't the one who had a problem with the script, nor with debugging. I am more than familiar enough with lua to have figured out to add prints (had I been running the script). I just assumed the people posting the script were also smart enough to use prints (because the script already clearly included prints), but if you were truly trying to be helpful, like I said, thanks... I guess.


Marko999x said:
Puting 1 as example instead of -1 or -2 or anything else worked :D
Click to expand...
See! I knew it! I knew the "weird behaviour" was attributed to using a negative number... negative numbers don't work the way people think they do.

I don't see any need in a "fix" if the way it was made was intentional, like sarah said:

Sarah Wesker said:
This way of ordering events is very good for several things, for example...
the onDropLoot events, or onGainExperience, ect...
Click to expand...
but I am however confused as to why people were saying it worked on 1.5 but not on 1.4.2... how can this be, I don't see any changes to the codebase...
 
Upvote 0 Downvote
There is no need to fix anything, except for the onMoveItem callback (due return values being numbers instead of booleans)
There is also no "weird behaviour" regarding to negative numbers when registering an event, you just need to understand how the order works.

When Marko999x registered a positive number instead of a negative, he forced his script to be executed after the default onMoveItem callback (index 0) and definitely as the last one, thats the only reason why it worked. If you don't set any number by default will be 0 and the order will depend in the way files were loaded or in the table.sort method from Lua.

Now, that being said, by fixing the onMoveItem the order shouldn't matter anymore. As soon as the callback system finds other value than RETURNVALUE_NOERROR it should block the item movement and stop the callback queue, same behaviour as the others callback types.
 
Upvote 0 Downvote
Roddet said:
There is no need to fix anything, except for the onMoveItem callback (due return values being numbers instead of booleans)
There is also no "weird behaviour" regarding to negative numbers when registering an event, you just need to understand how the order works.

When Marko999x registered a positive number instead of a negative, he forced his script to be executed after the default onMoveItem callback (index 0) and definitely as the last one, thats the only reason why it worked. If you don't set any number by default will be 0 and the order will depend in the way files were loaded or in the table.sort method from Lua.

Now, that being said, by fixing the onMoveItem the order shouldn't matter anymore. As soon as the callback system finds other value than RETURNVALUE_NOERROR it should block the item movement and stop the callback queue, same behaviour as the others callback types.
Click to expand...
That's incorrect to my experience.

If I have 4 scripts, that have ec:register() , then only the first one found would be executed.
All the other one's would not run.

1.4.2~
 
Upvote 0 Downvote
Xikini said:
That's incorrect to my experience.

If I have 4 scripts, that have ec:register() , then only the first one found would be executed.
All the other one's would not run.

1.4.2~
Click to expand...
Not true at all. Callbacks are pushed into an array as objects, not as a key <register index>.

github.com

TFS-1.5-Downgrades/data/scripts/lib/event_callbacks.lua at 8.60 · nekiro/TFS-1.5-Downgrades

Alternative forgottenserver versions for older protocols support - nekiro/TFS-1.5-Downgrades
github.com github.com
Same behaviour on TFS 1.4.2
 
Upvote 0 Downvote
Codinablack said:
Thanks.... I guess.
See, I wasn't the one who had a problem with the script, nor with debugging. I am more than familiar enough with lua to have figured out to add prints (had I been running the script). I just assumed the people posting the script were also smart enough to use prints (because the script already clearly included prints), but if you were truly trying to be helpful, like I said, thanks... I guess.



See! I knew it! I knew the "weird behaviour" was attributed to using a negative number... negative numbers don't work the way people think they do.

I don't see any need in a "fix" if the way it was made was intentional, like sarah said:


but I am however confused as to why people were saying it worked on 1.5 but not on 1.4.2... how can this be, I don't see any changes to the codebase...
Click to expand...
The normal thing is to use integer numbers, but it is possible to use numbers with decimals, it is strange but yes, lua allows it and there is no need to prohibit this
Negative numbers are also allowed, including special numbers like lowest infinity and highest infinity math.huge and -math.huge
If you do not pass any arguments to the register function, the default will be 0.
If two events have the same index, Lua will order them arbitrarily and there is no control over it.

Maybe more information about EventCallback should be added to the OTLand for TFS book.

Note, I had not read that @Roddet had already mentioned some points that I mentioned <3
 
Upvote 0 Downvote
I swear everytime I test this function it acts differently. lol

Sometimes the scripts don't execute. Sometimes they all execute. Sometimes they execute correctly, but don't function.

If I return false, the other scripts don't execute, but it also doesn't stop the item from moving.
If I return NOT_POSSIBLE, every script runs, and it acts like a return true.

somethings borked. idk what, and it seems like you guys are saying it's fixed, so I don't really care. xD
 
Upvote 0 Downvote
Sarah Wesker said:
The normal thing is to use integer numbers, but it is possible to use numbers with decimals, it is strange but yes, lua allows it and there is no need to prohibit this
Negative numbers are also allowed, including special numbers like lowest infinity and highest infinity math.huge and -math.huge
If you do not pass any arguments to the register function, the default will be 0.
If two events have the same index, Lua will order them arbitrarily and there is no control over it.

Maybe more information about EventCallback should be added to the OTLand for TFS book.

Note, I had not read that @Roddet had already mentioned some points that I mentioned <3
Click to expand...
Yes but its like you and roddet said, it defaults the index to 0. So for an average user, this isn't apparent, and it also makes it troublesome when mixing positives and negatives. I think it's just good practice to not use negative values here.... why would you need to? I mean its not like someone has thousands of events for one eventcallback... and even if they did, you already stated yourself that decimals are allowed. I would think it much cleaner to use decimals than negative values..

I think we should be discouraging the use of negative values for things like this, for sure.
Post automatically merged:

Xikini said:
I swear everytime I test this function it acts differently. lol

Sometimes the scripts don't execute. Sometimes they all execute. Sometimes they execute correctly, but don't function.

If I return false, the other scripts don't execute, but it also doesn't stop the item from moving.
If I return NOT_POSSIBLE, every script runs, and it acts like a return true.

somethings borked. idk what, and it seems like you guys are saying it's fixed, so I don't really care. xD
Click to expand...
In 1.4.2 it's not "fixed" it needs this commit

github.com

Optimization EventCallback by MillhioreBT · Pull Request #4237 · otland/forgottenserver

Pull Request Prelude I have followed [proper The Forgotten Server code styling][code]. I have read and understood the [contribution guidelines][cont] before making this PR. I am aware that this...
github.com github.com

Seems the issue was in lua the entire time, as roddet was saying before.

I think for black tek I will use the version luanluciano added to the nekiro downgrade, as it is much more readable, and also fixes the issue. if you want to find that commit it is here

github.com

Update EventCallbacks by luanluciano93 · Pull Request #133 · nekiro/TFS-1.5-Downgrades

Pull Request Prelude I have followed [proper The Forgotten Server code styling][code]. I have read and understood the [contribution guidelines][cont] before making this PR. I am aware that th...
github.com github.com
 
Upvote 0 Downvote
I just found something we could attribute the weird behavior on the system
github.com

TFS-1.5-Downgrades/data/scripts/lib/event_callbacks.lua at 8.60 · nekiro/TFS-1.5-Downgrades

Alternative forgottenserver versions for older protocols support - nekiro/TFS-1.5-Downgrades
github.com github.com
The system uses pairs as the iterator to iterate through an array, it should be ipairs to fully guaranteed the order of execution.

Xikini said:
If I return NOT_POSSIBLE, every script runs, and it acts like a return true.
Click to expand...
Even if you apply the fix I mentioned? For the onMoveItem
 
Upvote 0 Downvote

Similar threads

ohman
  • Question
Lua doRemoveItem() with stackable items
Replies
1
Views
122
Fjorda
F
Mjmackan
  • Question
TFS 1.X+ Moving onto TFS 1.4 lost functions
Replies
9
Views
711
Codinablack
Codinablack
J
  • Question
MAx item per tile tfs 1.5
Replies
3
Views
269
Dakos
D
alejandro762
  • Question
Bag allowing certain items , similar (Gold Pouch)
Replies
1
Views
323
alejandro762
alejandro762
J
  • Question
TFS 1.X+ data/events/scripts/player.lua:Player@onLookInShop
Replies
1
Views
337
Mateus Robeerto
Mateus Robeerto
Mateus Robeerto
  • Question
TFS 1.X+ I have doubts about onMoveItem or another function tfs 1.4.2
Replies
5
Views
398
domciacho
D
beenii
  • Solved
RME Map editor, how to make item unmovable? TFS 1.4.2
Replies
5
Views
681
beenii
beenii
richardestro
  • Question
Error with firestorm Revscript
Replies
4
Views
146
Fjorda
F
Djivar
  • Question
Svarground script TFS 1.4.2 [10.98]
Replies
3
Views
429
mano368
M
OTcreator
  • Solved
TFS 1.X+ onDrop console error.
Replies
11
Views
494
OTcreator
OTcreator
Back
Top