I would like to propose that the devs consider making the weight propertiy of items read/write instead of read only.
This would facilitate new avenues of magical items. An example of one such item is a magic bag of holding.
Read / Write on weight of items
Moderator: POL Developer
-
Marilla
I think I like this idea; just a couple things...
First: I think they'd have to be careful how this affects things like the .weight member on containers, which currently shows the total weight of all items in the container. I very much like that particular feature of the .weight property being R/O.
Perhaps, though, the .weight property could be implemented differently for reading/writing; When you set the .weight prop on an item, it merely sets the item's internal weight member, even if the item is a container. Reading the .weight prop would then STILL return the total weight of the container, plus all items.
Meaning that setting the weight of a container with stuff in it, and immediately reading back that property would result in different values.
Alternatively, a new member could be added which would get the total weight of an item, with all contained items, and then .weight could set/return ONLY the item's weight itself.
---------------
Finally, I think there's also something else Kiko wants to ask for here; for purposes of actually making a bag of holding, it would seem more useful to be able to set the weight/item limits, as opposed to setting the weight on items. Of course, an alternative way to implement such an item would be by having multiple defined items, with different weight limits on each. I think some people might trip up on the 'worn items container', though; as regardless of how much a bag you are carrying can handle, you are still limited by what the 'worn items container' allows. (which can be fixed easily by modifying THAT item's definition - though care must be taken to assure other issues are not created instead!)
First: I think they'd have to be careful how this affects things like the .weight member on containers, which currently shows the total weight of all items in the container. I very much like that particular feature of the .weight property being R/O.
Perhaps, though, the .weight property could be implemented differently for reading/writing; When you set the .weight prop on an item, it merely sets the item's internal weight member, even if the item is a container. Reading the .weight prop would then STILL return the total weight of the container, plus all items.
Meaning that setting the weight of a container with stuff in it, and immediately reading back that property would result in different values.
Alternatively, a new member could be added which would get the total weight of an item, with all contained items, and then .weight could set/return ONLY the item's weight itself.
---------------
Finally, I think there's also something else Kiko wants to ask for here; for purposes of actually making a bag of holding, it would seem more useful to be able to set the weight/item limits, as opposed to setting the weight on items. Of course, an alternative way to implement such an item would be by having multiple defined items, with different weight limits on each. I think some people might trip up on the 'worn items container', though; as regardless of how much a bag you are carrying can handle, you are still limited by what the 'worn items container' allows. (which can be fixed easily by modifying THAT item's definition - though care must be taken to assure other issues are not created instead!)
-
Yukiko
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Well, as I understand a magic bag of holding from my "D&D days" is that you could drop things into it without it adding to the weight you are carrying.
My concept would apply to items only and not those of type container. Not sure if POL could do a check for this.
The oninsert script would take say 1/2 of the items weight off upon insertion and then upon removal the items original weight would be restored. A fairly staright forward script if POL allowed it. Ofcourse this script would have a maxweight value. After reaching this value the bag will no longer modify the weight of items.
I realize the implications here for complicating the internal workings of POL and the possible conflicts with the static entries in the itemdesc files. Also, upon a server restart I am not sure how POL would handle items in a scripted magic bag of holding that had their weight changed dynamically. In my original idea POL would simply load the original weight values from the itemdesc files on a restart. But now that I think about it if the weight is changed by the oninssert script, when POL restarts it would reassign weights per the entries in itemdesc file. Thisd might cause the weight limit of the container to be exceeded and thus items would spill out of the container.
*thinks*
I guess there could be a second weight member that would hold a modified weight value. POL could check that to see if it is set to anything other than zero and if it is use that instead of the trueweight. This would be similar to the way colour works with the members color and truecolor.
My concept would apply to items only and not those of type container. Not sure if POL could do a check for this.
The oninsert script would take say 1/2 of the items weight off upon insertion and then upon removal the items original weight would be restored. A fairly staright forward script if POL allowed it. Ofcourse this script would have a maxweight value. After reaching this value the bag will no longer modify the weight of items.
I realize the implications here for complicating the internal workings of POL and the possible conflicts with the static entries in the itemdesc files. Also, upon a server restart I am not sure how POL would handle items in a scripted magic bag of holding that had their weight changed dynamically. In my original idea POL would simply load the original weight values from the itemdesc files on a restart. But now that I think about it if the weight is changed by the oninssert script, when POL restarts it would reassign weights per the entries in itemdesc file. Thisd might cause the weight limit of the container to be exceeded and thus items would spill out of the container.
*thinks*
I guess there could be a second weight member that would hold a modified weight value. POL could check that to see if it is set to anything other than zero and if it is use that instead of the trueweight. This would be similar to the way colour works with the members color and truecolor.
-
Marilla
I recall some concerns about the memory usage such an addition would require, yes. Making any member read/write means that EVERY single item instance must store that value, whereas now, that is not the case. That's definitely a concern.Pierce wrote:I think the devs do a statement on that before (old forum), because it would consume a lot of memory, I am not quite sure.
-
Firedancer
- Grandmaster Poster
- Posts: 104
- Joined: Fri Feb 03, 2006 6:32 am
- Location: Austria
- Contact:
is it? Have you ever checked how many r/w properties an item has? color, graphic and whatnot.... I seriously doubt a single additional integer would break that.Marilla wrote:I recall some concerns about the memory usage such an addition would require, yes. Making any member read/write means that EVERY single item instance must store that value, whereas now, that is not the case. That's definitely a concern.Pierce wrote:I think the devs do a statement on that before (old forum), because it would consume a lot of memory, I am not quite sure.
Though I guess there might be ways to say unless modified -> value not stored ==> default being used. (E.g. worst case make a pol.cfg switch, to have it r/w or r/o? nah, bad option.)
Thinking though, that e.g. on smithing I'd no longer have to define a new sword itemdesc.cfg entry for every possible material (thus different weight) it would really help a lot - I fully vote for this option!
-
Marilla
-
Yukiko
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Well, I still vote for it.
I want someone to explain to me how one more integer is going to affect memory usage to cause it to be a critical issue.
I would like to hear from Melanius or Austin on this or one of the other developers.
Can one of you (a developer) just comment on whether one more integer member added to all items in an average or larger than average shard would be that critical that it would become a concern? My thought would be that the current value known as "weight" would be the true weight and a second integer member would be the "dynamic" weight. That could be a read/write value. Well, I explained that concept above.
I want someone to explain to me how one more integer is going to affect memory usage to cause it to be a critical issue.
I would like to hear from Melanius or Austin on this or one of the other developers.
Can one of you (a developer) just comment on whether one more integer member added to all items in an average or larger than average shard would be that critical that it would become a concern? My thought would be that the current value known as "weight" would be the true weight and a second integer member would be the "dynamic" weight. That could be a read/write value. Well, I explained that concept above.
-
Firedancer
- Grandmaster Poster
- Posts: 104
- Joined: Fri Feb 03, 2006 6:32 am
- Location: Austria
- Contact:
good idea yes.Yukiko wrote:Well, I still vote for it.
I want someone to explain to me how one more integer is going to affect memory usage to cause it to be a critical issue.
I would like to hear from Melanius or Austin on this or one of the other developers.
Can one of you (a developer) just comment on whether one more integer member added to all items in an average or larger than average shard would be that critical that it would become a concern? My thought would be that the current value known as "weight" would be the true weight and a second integer member would be the "dynamic" weight. That could be a read/write value. Well, I explained that concept above.