Lua [TFS 1.4] Changing item uid, is this problematic?

[krafttomten]

Greetings dear otlanders!

Changing an items uniqueid in lua is forbidden through luascript.cpp.

if (ItemAttributes::isIntAttrType(attribute)) {
         if (attribute == ITEM_ATTRIBUTE_UNIQUEID) {
             reportErrorFunc(L, "Attempt to set protected key \"uid\"");
             pushBoolean(L, false);
             return 1;
         }

Without this ^ restriction it be possible using the following code:

saidItem:setAttribute(ITEM_ATTRIBUTE_UNIQUEID, 1337)

With an unmodified luascript.cpp this returns the error message "Attempt to set protected key 1337" However, the lua code can be made to work by simply commenting out the attached piece of luascript.cpp (i.e. lines 6877-6881)

Now, I am sure that I am not the only one here getting a slight feeling of discomfort when haphazardly removing safety features I do not fully understand. So I wish to know better what damage I might have caused.
Basically, why is uniqueIds protected?
Will the universe now implode due to my negligence?

Input would be much appreciated, spreading knowledge is beneficial for all of us.

 

[oen432]

You would have to remove it from unique items list in Game object and readd when changing id.
However first of all... why do you want to do this? Why not use action id?

 

[krafttomten]

You would have to remove it from unique items list in Game object and readd when changing id.
However first of all... why do you want to do this? Why not use action id?

Okay, so if I do not remove it from Game I would get duplicate uids referencing the same object, but in different ways, which could cause troubles.. or something like that.. That seems bad..

The reason I did it was because I have a daily quest reward chest system which uses the actionId to trigger the code and the uniqueId to convey what storage value should be used for the specific daily quest. This way I can use the same code for many quest chests, but different timers, rewards, level limits, etc, for each.

In this case, I wished to randomize the location for one of the reward chests. So I figured I could create the reward chest in the onstartup.lua, instead of adding it through RME. But concidering your answer, I think it might be a better idea to simply spawn it in with RME in a temporary location, then move it to a random location through the startup.lua. That would yield the same end results, but without the troubles of making an item with a specific uid through lua.

 

[M4rcin]

Okay, so if I do not remove it from Game I would get duplicate uids referencing the same object, but in different ways, which could cause troubles.. or something like that.. That seems bad..

The reason I did it was because I have a daily quest reward chest system which uses the actionId to trigger the code and the uniqueId to convey what storage value should be used for the specific daily quest. This way I can use the same code for many quest chests, but different timers, rewards, level limits, etc, for each.

In this case, I wished to randomize the location for one of the reward chests. So I figured I could create the reward chest in the onstartup.lua, instead of adding it through RME. But concidering your answer, I think it might be a better idea to simply spawn it in with RME in a temporary location, then move it to a random location through the startup.lua. That would yield the same end results, but without the troubles of making an item with a specific uid through lua.

That is one way to do it, you could also Game::addUniqueItem, but why bother doing all that?
If actionId is not enough there are custom attributes (you can use Item::setCustomAttribute to set them), and these will serve you way better.

 

[krafttomten]

That is one way to do it, you could add it using Game::addUniqueItem, but you'll have to bind it.
BTW If actionId is not enough there are custom attributes Item::setCustomAttribute, and these will serve you way better.

Thanks for your reply! Having to "bind it" means that I have to make the function available through the luaScriptInterface, correct?

And Item::setCustomAttribute is somehow different from Item::setAttribute, so I'll look into that aswell Having the option to make specific unique ids through the lua interface would be a great asset to have. I'm not yet sure what I would need it for... But experience tells me that the more options I have, the less restricted my imagination becomes when implementing new stuff to my server

 

[M4rcin]

Thanks for your reply! Having to "bind it" means that I have to make the function available through the luaScriptInterface, correct?

And Item::setCustomAttribute is somehow different from Item::setAttribute, so I'll look into that aswell Having the option to make specific unique ids through the lua interface would be a great asset to have. I'm not yet sure what I would need it for... But experience tells me that the more options I have, the less restricted my imagination becomes when implementing new stuff to my server

The thing is UID usually serves a different purpose and there are possible difficulties (UID collisions and such), so I'm not sure if you should abuse it. I'm like 99% sure there are no consequences of doing so, but it seems like a bad practice when actually, all you really want is to set a custom attribute to an item - there is a method for that

 

[krafttomten]

The thing is UID usually serves a different purpose and there are possible difficulties (UID collisions and such), so I'm not sure if you should abuse it. I'm like 99% sure there are no consequences of doing so, but it seems like a bad practice when actually, all you really want is to set a custom attribute to an item - there is a method for that

Oh, you mean it like that. In that case, I have made sure that I do not assign multiple items with the same UID. In this special aforementioned situation, it seems that I potentially did so, which is why I am no longer trying to make a specific UID through lua using Item::setAttribute. It does not seem to be worth the effort to manipulate the contents of the Game object when there are simpler and safer ways to achieve the same result

Using uniqueId to identify one specific reward chest is not an issue in itself.